I know it sounds crazy, but some people have moral hangups about killing people unnecessarily.
Only some people. Why are we even paying our taxes to the RIAA if they're not upholding their end of the bargain and keeping the seas free of pirate scum and villainy?
You are comparing ARM to some vague memory that you have of how x86 used to perform several generations ago. To expand on what the AC was saying with some actual details. The Core2 (and the core-7 / Sandy Bridge) all have three pipes per core for MOV and simple ALU operations. For register to register operations it is very easy to hit maximum throughput on these (in fact if you have enough registers for your problem is very hard to stall these pipes at all).
The throughput of MOV/ ADD/ SUB/ MUL is 3 operations per clock. The latency of MOV and simple ALU stuff is one clock cycle. The MUL has a latency of 4 clocks. To compare to your claim these types of instructions are about 3x faster on x86 per clock than on ARM, where-as you claimed it was 1/3 of the speed. You are out by an order of magnitude.
Caching is much more complex so I won't say too much there, but if the working set of your code drops below a certain threshold on x86 then performance-wise the cache disappears and it looks like your pages are a giant register bank.
I can paste into replies quite easily. Check your browser.
Unrelated WTF: Why can I no longer paste into Slashdot text boxes? Is this some kind of anti-troll thing? It makes it a bitch to add links. I would have linked to the related posts directly, but I can't be bothered to type them in. The relevant dates are March 16, 2010 (Windows theme, showing native file panels) and December 29, 2010 (GNOME theme, showing GNOME-like menus, buttons, and so on).
Your original point was that a reconfigurable processor would be more efficient at most tasks than a specialised processor, and that the big issue would be handling security. Why resort to car analogies when your entire argument can be summarised so concisely?
I have made a simple enough argument that you seem to keep missing - while it is a nice theory that we can reconfigure chips to be more efficient for a particular task the actual practice doesn't live up to expectations. Reconfigurable architectures have a cost - you must account for all possible communication patterns rather than a single specialised instance. As such you must spend more die space on interconnect logic. As a result the building blocks for reconfigurable systems are slower than specialised logic.
Stop using poor measurements - 20 cycles of what? I can make a computing device entirely out of lard that will compute AES in 20 cycles, but unfortunately the clock speed will be measured in billions of years. It doesn't compare. Compare actual performance for actual performance. Specialised chips win on most applications leaving only a few cases where reconfigurable logic can compete.
It's not so much about the eating of and having of cake. It's more about demanding that Intel ship you cake in time for there to be cake there when you are hungry (that you can both eat and have).
It's a bitchy whiney ridiculous complaint - and yet it is a good thing as it puts pressure on Intel and AMD to treat Linux support as something necessary for a launch. Hopefully it won't result in Intel pointing out that there is no cake...
Well.... no. A few percent is a small deal. A larger percentage would be a bigger deal.
You've made a critical failure here: the x86 *instruction* cache stores x86 instructions after they've been decoded into simpler RISCy form
Yes - after they've been transferred across the bottleneck from memory. So at the point where it matters (the cache fetching lines from memory) the code is in a dense form because of the CISC encoding.
It's really quite simple: RISC is an advantage where the cost of decoding dominates because it simplifies the decoder circuitry. CISC is an advantage where the cost of transferring instructions (and the space that they occupy in memory) is the dominant cost because it reduces the size of the code.
Wisdom and BS, eh? That's the nicest thing I've heard on slashdot in a while...
It's odd that you pick crypto as I've spent a little time implementing crypto primitives on weird and exotic hardware. Sure - division is quite slow, that is why most primitives avoid the need for it, or only perform reductions in a specialised field rather than a full division. Multiplication on the other hand is fast and tends to be used a lot.
AES is quite a bad example for FPGAs. The very latest AES extensions from Intel can compute a round of AES in under three clock cycles. Performing the full cipher takes less than twenty clock cycles (on a processor running in excess of 3Ghz). No FPGA in the world can keep up with that performance.
Even if you do implement AES on an FPGA there is a basic issue caused by operations on the state matrix being defined over 8-bit elements while the lookup tables in FPGAs are generally 6-4-bit tables. This means splitting the element operations over multiple slices in the FPGA so the entire round needs to be unfolded over a large chunk of the available space. Even then you've just made the propagation delay in the circuit equal to the clock-speed of the device, while in the x86 equivalent the circuit propagation delay is somewhere under 0.033ns.
I can't be bothered to look up the latest results, but Bernstein's code on the x86 is probably still the fastest for general chips at about 9cycles/byte. Using bit-slicing can take that down to about 5cyc/byte or about 800MB/s. The biggest bottleneck on an FPGA is the terrible clock-speed imposed by the terrible layout tools that you are forced to use. Ignoring real I/O performance can the latest FPGA boards get close to that speed? It would mean delivering 32-bits/cycle on a 200Mhz clock which is a lot better than any AES on FPGA papers than I've read in a while.
Of course the new extension blow that away as 3 cycles/round is slightly less than 1cycle/byte or 3GB/s on a newer processor. As that is my main area of expertise I'll comment less on your other examples. Your basic argument about pipelining in general is wrong though.
In order for there to be a large improvement in speed from pipelining combinations of instructions rather than single instructions you must have some overhead in each cycle that is time being wasted for synchronisation. Time that could be reclaimed by combining the stages. There just isn't that much overhead to be reclaimed in a modern x86 design. The simpler operations feature dual-despatch and the more complex operations use larger circuits to ensure that their execution time is as close to a multiple of two executions of the simpler operations as possible.
Unless you are exploiting overhead within the cycle then in order to be more efficient you have to exploit overhead between cycles. Have you looked closely at the despatch patterns on a modern x86 core? It is very hard to stall the pipelines and the ROB is deep enough to make many operations invisible from a performance perspective. And of course this is all running on a 3Ghz clock with very low latencies (less than 4 cycles for a MUL).
As I said originally there are applications where FPGAs can win: but they are nowhere near as common as people thought. The advantages just don't stack up when you compare them against specialised circuits. In particular the horrific bottlenecks on clock-speed that using that much interconnect creates means that you need a particularly suitable application to beat a specialised CPU at all - and the chances for a reconfigurable processor that can win on many applications is slim to remote.
This sounds reminiscent of the hype around reconfigurable computing ten years ago. A lot of the hype has died down now that people have tried and discovered that what you've described is wrong.
First point: a specialised hardware circuit will always be faster than a generic circuit.
Second point: generic circuits require a lot more interconnect than specialised circuits which impacts how many of them you can fit on a die relative to specialised circuits.
Third point: a CPU is a set of specialised circuits being selected for execution by the program.
So here is the basic problem. If the target application is made of steps that exist as specialised circuits in the CPU then selecting which of those circuits to apply in sequence will be faster than a generic circuit because the specialised circuit uses the space on the die more effectively and is clocked at a much higher frequency.
If the target application is made of steps which are very unlike the circuits provided on the CPU then the generic design will win. For everything in-between it is a trade-off. Not as many things win as FPGA designs and there is ten years of literature showing marginal improvements.
The problem is not some far-fetched security issue - the real problem for FPGAs is that the instruction set chosen for most processors covers most problems adequately well. There are very few corner cases where an FPGA can win convincingly, and certainly no demand for a reconfigurable processor.
Sigh. Multi-way branching was already old when ARM implemented it. What you fail to explain (understand?) is that there is a cost associated with either choice. As with most of engineering there is not a simple proposal that wins. In the case that branch prediction is perfect, the predicted execution is cheaper. In the case that the prediction is terrible the multi-way execution wins. In real life branch prediction is neither perfect, nor is it that terrible, so engineers have to balance the likelihood that one technique will be better for a given type of code against the probability that the processor will execute that type of code.
Guess where multi-way branching wins? In small working-set loads typical of embedded processing applications. Guess where branch prediction wins? On a more general set of benchmarks typical of desktop computing.
Your other point is equally incorrect - the decoding overhead for x86 is now minimal (a few percent of the size of the core). However the x86 instruction set is very good at packing lots of code into a small amount of space, which given the effectiveness of the x86 instruction cache is why it destroyed most of the pure-RISC competition. Those unused instructions are not "sitting in the silicon" as you put it rather idiotically. What they are doing is sitting in longer instruction words in the x86 encoding allowing the more frequently used instructions to be encoded in less space. It's a very simple form of compression, and as with other engineering tradeoffs it can win and lose in different circumstances but in the particular case of most x86 benchmarks it beats other instruction encodings.
Seriously, x86 is SO FREAKIN' OLD, it has been finely tuned and matured with age.
652 in particular seems like a weird one. The patent was filed in '96 and Windows gained the taskbar in '95 with widgets that display notifications. It's not even as if the windows taskbar was the first to do this, but it is a mainstream application that meets the specific claims that are being cited a year before the patent was filed.
You seem to be missing the forest for the trees. If they spend more time typing then they spend less time writing code. If they write less to compensate then the original post explained how this impacted the quality of their code.
No, it cannot be assumed that they take either route A or route B, but as both routes lead to a worse place for coding then it is safe to assume that a worse place for coding will be reached.
Although your point holds in general, when both choices lead to the same result it no longer matter which choice is taken. Lastly, if you are being quite so picky then it is important to be absolutely correct yourself: "easy to believe" is a synonym for "reasonable probability of being true". As such the two things are not "very different", but merely different.
The "sweeping generalisation" was that people who type slowly will type less. Not that hard to believe. If you insist on him being logically complete then he could expand it: people who type slowly *must* either type less or spend more time typing.
Do you believe that slower typists put in more hours, or just accept that when posting something quite so stupid you should click the anonymous box?
And while that slows things down in America the rest of the world will just quietly carry on rolling out next-generation infrastructure such as this. It's available now, my Swedish isn't good enough to spot what kind of technology it is but 80Mb wireless broadband sounds pretty 4G to me.
How does increasing the number of registers reduce churn in encryption? The working-set is far too large to fit in the larger number of registers anyway so it has little effect. In AES there is a 256byte/4096byte lookup table (depending on the implementation) and accesses into it are randomly distributed. On the public key side even with a tiny 1024-bit key the working-set is a 16x16 word set of partial products and it needs to be computed in some order to minimise memory traffic.
If you replace anyone with somebody then we are using the same definition. In cryptography you generally don't know who the adversary is, and so the standard definition of eavesdropping means that anybody is capable of listening in.
When you connect to an encrypted service you are not just placing your trust in that service: without authentication you are trusting whoever you have actually connected to.
When you connect to an encrypted (but none authenticated) service you are placing your trust in an unknown entity - not the the service that you think that you are placing your trust in.
The key point is that you have not eliminated eavesdropping - there is only the appearance that you have. In order to eavesdrop the attacker just performs the MITM and offers you a fake router. Without authentication there is no protection against this.
In many ways encryption with authentication is like airport security - it's just there for show.
Don't forget that "somebody bothered to setup a MITM to get my facebook password" becomes somebody used an automated attack to swipe credentials for *everybody* here.... Big scoop and then then filter. You'd be amazed how many people reuse a "secure" password for a server like facebook.
Where you say that anyone can listen in between the router and facebook.... this is true, but it seems to imply that traffic between you and the router is private from other people. This is not true in the case that you don't have trust (authentication). Unless you authenticate the router you are open to impersonation / man-in-the-middle attacks. For wpa2 there are extra authentication layers that solve this problem (e.g eap), but these are examples of encryption with trust - not without.
It would seem that you are tired of it before you have even understood it. Encryption without trust does not provide privacy - just the appearance of privacy, which is worse than useless.
Your example is wrong because without trust encrypting that first hop doesn't even stop other people on the router listening in - it just makes you think that it does. So it is not even the first in a complete solution.
1. As a straw man attacking people with a rightful opposition to invasive DRM schemes.
Err, what? That doesn't actually make any sense - did you mistype or something?
Starting from the back (learn to use shorter sentences / clauses) "a rightful opposition to invasive DRM schemes". Ok, hardly objective but I agree that DRM is invasive and that opposition to it is right so we can let that go. "As a straw man attacking people...." - so the thing that you are talking about must be a strawman argument against this rightful opposition... information wants to be free?
So you think information wants to be free is a strawman attacking people who are against DRM? Nah, doesn't make any sense at all.
You could trim your toenails with an axe - but it is not the best way to get the job done. It's slow. It's clunky. Animation and effects aren't synced properly to updates. The battery life is terrible and anything to do the same but with less power would be a blessing. When Wayland comes out on MeeGo I'll try it.
I can already see how many posts here will be about how dumb the game is and how only dumb people play it, but I don't think it matters. People like it and the company is making more money than EA.
Nah, I reckon the posts will be about how dumb people are that take made up numbers at face value. Zynga is not a public traded company and if you dig back through the links to the source then the five billion dollar figure is an estimate.
Slashdot Mirror
I know it sounds crazy, but some people have moral hangups about killing people unnecessarily.
Only some people. Why are we even paying our taxes to the RIAA if they're not upholding their end of the bargain and keeping the seas free of pirate scum and villainy?
You are comparing ARM to some vague memory that you have of how x86 used to perform several generations ago. To expand on what the AC was saying with some actual details. The Core2 (and the core-7 / Sandy Bridge) all have three pipes per core for MOV and simple ALU operations. For register to register operations it is very easy to hit maximum throughput on these (in fact if you have enough registers for your problem is very hard to stall these pipes at all).
The throughput of MOV/ ADD/ SUB/ MUL is 3 operations per clock. The latency of MOV and simple ALU stuff is one clock cycle. The MUL has a latency of 4 clocks. To compare to your claim these types of instructions are about 3x faster on x86 per clock than on ARM, where-as you claimed it was 1/3 of the speed. You are out by an order of magnitude.
Caching is much more complex so I won't say too much there, but if the working set of your code drops below a certain threshold on x86 then performance-wise the cache disappears and it looks like your pages are a giant register bank.
I can paste into replies quite easily. Check your browser.
Unrelated WTF: Why can I no longer paste into Slashdot text boxes? Is this some kind of anti-troll thing? It makes it a bitch to add links. I would have linked to the related posts directly, but I can't be bothered to type them in. The relevant dates are March 16, 2010 (Windows theme, showing native file panels) and December 29, 2010 (GNOME theme, showing GNOME-like menus, buttons, and so on).
A quote that I stole from a real argument on slashdot. It's like you're giving me deja vu... it just makes it even more true.
Your original point was that a reconfigurable processor would be more efficient at most tasks than a specialised processor, and that the big issue would be handling security. Why resort to car analogies when your entire argument can be summarised so concisely?
I have made a simple enough argument that you seem to keep missing - while it is a nice theory that we can reconfigure chips to be more efficient for a particular task the actual practice doesn't live up to expectations. Reconfigurable architectures have a cost - you must account for all possible communication patterns rather than a single specialised instance. As such you must spend more die space on interconnect logic. As a result the building blocks for reconfigurable systems are slower than specialised logic.
Stop using poor measurements - 20 cycles of what? I can make a computing device entirely out of lard that will compute AES in 20 cycles, but unfortunately the clock speed will be measured in billions of years. It doesn't compare. Compare actual performance for actual performance. Specialised chips win on most applications leaving only a few cases where reconfigurable logic can compete.
It's not so much about the eating of and having of cake. It's more about demanding that Intel ship you cake in time for there to be cake there when you are hungry (that you can both eat and have).
It's a bitchy whiney ridiculous complaint - and yet it is a good thing as it puts pressure on Intel and AMD to treat Linux support as something necessary for a launch. Hopefully it won't result in Intel pointing out that there is no cake...
Nice. The circle is now complete. We can all be satisfied with what we have wrought.
Well.... no. A few percent is a small deal. A larger percentage would be a bigger deal.
You've made a critical failure here: the x86 *instruction* cache stores x86 instructions after they've been decoded into simpler RISCy form
Yes - after they've been transferred across the bottleneck from memory. So at the point where it matters (the cache fetching lines from memory) the code is in a dense form because of the CISC encoding.
It's really quite simple: RISC is an advantage where the cost of decoding dominates because it simplifies the decoder circuitry. CISC is an advantage where the cost of transferring instructions (and the space that they occupy in memory) is the dominant cost because it reduces the size of the code.
Wisdom and BS, eh? That's the nicest thing I've heard on slashdot in a while...
It's odd that you pick crypto as I've spent a little time implementing crypto primitives on weird and exotic hardware. Sure - division is quite slow, that is why most primitives avoid the need for it, or only perform reductions in a specialised field rather than a full division. Multiplication on the other hand is fast and tends to be used a lot.
AES is quite a bad example for FPGAs. The very latest AES extensions from Intel can compute a round of AES in under three clock cycles. Performing the full cipher takes less than twenty clock cycles (on a processor running in excess of 3Ghz). No FPGA in the world can keep up with that performance.
Even if you do implement AES on an FPGA there is a basic issue caused by operations on the state matrix being defined over 8-bit elements while the lookup tables in FPGAs are generally 6-4-bit tables. This means splitting the element operations over multiple slices in the FPGA so the entire round needs to be unfolded over a large chunk of the available space. Even then you've just made the propagation delay in the circuit equal to the clock-speed of the device, while in the x86 equivalent the circuit propagation delay is somewhere under 0.033ns.
I can't be bothered to look up the latest results, but Bernstein's code on the x86 is probably still the fastest for general chips at about 9cycles/byte. Using bit-slicing can take that down to about 5cyc/byte or about 800MB/s. The biggest bottleneck on an FPGA is the terrible clock-speed imposed by the terrible layout tools that you are forced to use. Ignoring real I/O performance can the latest FPGA boards get close to that speed? It would mean delivering 32-bits/cycle on a 200Mhz clock which is a lot better than any AES on FPGA papers than I've read in a while.
Of course the new extension blow that away as 3 cycles/round is slightly less than 1cycle/byte or 3GB/s on a newer processor. As that is my main area of expertise I'll comment less on your other examples. Your basic argument about pipelining in general is wrong though.
In order for there to be a large improvement in speed from pipelining combinations of instructions rather than single instructions you must have some overhead in each cycle that is time being wasted for synchronisation. Time that could be reclaimed by combining the stages. There just isn't that much overhead to be reclaimed in a modern x86 design. The simpler operations feature dual-despatch and the more complex operations use larger circuits to ensure that their execution time is as close to a multiple of two executions of the simpler operations as possible.
Unless you are exploiting overhead within the cycle then in order to be more efficient you have to exploit overhead between cycles. Have you looked closely at the despatch patterns on a modern x86 core? It is very hard to stall the pipelines and the ROB is deep enough to make many operations invisible from a performance perspective. And of course this is all running on a 3Ghz clock with very low latencies (less than 4 cycles for a MUL).
As I said originally there are applications where FPGAs can win: but they are nowhere near as common as people thought. The advantages just don't stack up when you compare them against specialised circuits. In particular the horrific bottlenecks on clock-speed that using that much interconnect creates means that you need a particularly suitable application to beat a specialised CPU at all - and the chances for a reconfigurable processor that can win on many applications is slim to remote.
Maybe I was a little hasty. Now that you've explained it I'm seeing a certain similarity to Novell...
That would have worked better as an analogy if you hadn't fucked up the most relevant part.
This sounds reminiscent of the hype around reconfigurable computing ten years ago. A lot of the hype has died down now that people have tried and discovered that what you've described is wrong.
First point: a specialised hardware circuit will always be faster than a generic circuit.
Second point: generic circuits require a lot more interconnect than specialised circuits which impacts how many of them you can fit on a die relative to specialised circuits.
Third point: a CPU is a set of specialised circuits being selected for execution by the program.
So here is the basic problem. If the target application is made of steps that exist as specialised circuits in the CPU then selecting which of those circuits to apply in sequence will be faster than a generic circuit because the specialised circuit uses the space on the die more effectively and is clocked at a much higher frequency.
If the target application is made of steps which are very unlike the circuits provided on the CPU then the generic design will win. For everything in-between it is a trade-off. Not as many things win as FPGA designs and there is ten years of literature showing marginal improvements.
The problem is not some far-fetched security issue - the real problem for FPGAs is that the instruction set chosen for most processors covers most problems adequately well. There are very few corner cases where an FPGA can win convincingly, and certainly no demand for a reconfigurable processor.
Sigh. Multi-way branching was already old when ARM implemented it. What you fail to explain (understand?) is that there is a cost associated with either choice. As with most of engineering there is not a simple proposal that wins. In the case that branch prediction is perfect, the predicted execution is cheaper. In the case that the prediction is terrible the multi-way execution wins. In real life branch prediction is neither perfect, nor is it that terrible, so engineers have to balance the likelihood that one technique will be better for a given type of code against the probability that the processor will execute that type of code.
Guess where multi-way branching wins? In small working-set loads typical of embedded processing applications. Guess where branch prediction wins? On a more general set of benchmarks typical of desktop computing.
Your other point is equally incorrect - the decoding overhead for x86 is now minimal (a few percent of the size of the core). However the x86 instruction set is very good at packing lots of code into a small amount of space, which given the effectiveness of the x86 instruction cache is why it destroyed most of the pure-RISC competition. Those unused instructions are not "sitting in the silicon" as you put it rather idiotically. What they are doing is sitting in longer instruction words in the x86 encoding allowing the more frequently used instructions to be encoded in less space. It's a very simple form of compression, and as with other engineering tradeoffs it can win and lose in different circumstances but in the particular case of most x86 benchmarks it beats other instruction encodings.
Seriously, x86 is SO FREAKIN' OLD, it has been finely tuned and matured with age.
652 in particular seems like a weird one. The patent was filed in '96 and Windows gained the taskbar in '95 with widgets that display notifications. It's not even as if the windows taskbar was the first to do this, but it is a mainstream application that meets the specific claims that are being cited a year before the patent was filed.
You seem to be missing the forest for the trees. If they spend more time typing then they spend less time writing code. If they write less to compensate then the original post explained how this impacted the quality of their code.
No, it cannot be assumed that they take either route A or route B, but as both routes lead to a worse place for coding then it is safe to assume that a worse place for coding will be reached.
Although your point holds in general, when both choices lead to the same result it no longer matter which choice is taken. Lastly, if you are being quite so picky then it is important to be absolutely correct yourself: "easy to believe" is a synonym for "reasonable probability of being true". As such the two things are not "very different", but merely different.
Really?
The "sweeping generalisation" was that people who type slowly will type less. Not that hard to believe. If you insist on him being logically complete then he could expand it: people who type slowly *must* either type less or spend more time typing.
Do you believe that slower typists put in more hours, or just accept that when posting something quite so stupid you should click the anonymous box?
And while that slows things down in America the rest of the world will just quietly carry on rolling out next-generation infrastructure such as this. It's available now, my Swedish isn't good enough to spot what kind of technology it is but 80Mb wireless broadband sounds pretty 4G to me.
How does increasing the number of registers reduce churn in encryption? The working-set is far too large to fit in the larger number of registers anyway so it has little effect. In AES there is a 256byte/4096byte lookup table (depending on the implementation) and accesses into it are randomly distributed. On the public key side even with a tiny 1024-bit key the working-set is a 16x16 word set of partial products and it needs to be computed in some order to minimise memory traffic.
If you replace anyone with somebody then we are using the same definition. In cryptography you generally don't know who the adversary is, and so the standard definition of eavesdropping means that anybody is capable of listening in.
When you connect to an encrypted service you are not just placing your trust in that service: without authentication you are trusting whoever you have actually connected to.
When you connect to an encrypted (but none authenticated) service you are placing your trust in an unknown entity - not the the service that you think that you are placing your trust in.
The key point is that you have not eliminated eavesdropping - there is only the appearance that you have. In order to eavesdrop the attacker just performs the MITM and offers you a fake router. Without authentication there is no protection against this.
In many ways encryption with authentication is like airport security - it's just there for show.
Don't forget that "somebody bothered to setup a MITM to get my facebook password" becomes somebody used an automated attack to swipe credentials for *everybody* here.... Big scoop and then then filter. You'd be amazed how many people reuse a "secure" password for a server like facebook.
Where you say that anyone can listen in between the router and facebook.... this is true, but it seems to imply that traffic between you and the router is private from other people. This is not true in the case that you don't have trust (authentication). Unless you authenticate the router you are open to impersonation / man-in-the-middle attacks. For wpa2 there are extra authentication layers that solve this problem (e.g eap), but these are examples of encryption with trust - not without.
It would seem that you are tired of it before you have even understood it. Encryption without trust does not provide privacy - just the appearance of privacy, which is worse than useless.
Your example is wrong because without trust encrypting that first hop doesn't even stop other people on the router listening in - it just makes you think that it does. So it is not even the first in a complete solution.
Err, what? That doesn't actually make any sense - did you mistype or something?
Starting from the back (learn to use shorter sentences / clauses) "a rightful opposition to invasive DRM schemes". Ok, hardly objective but I agree that DRM is invasive and that opposition to it is right so we can let that go. "As a straw man attacking people...." - so the thing that you are talking about must be a strawman argument against this rightful opposition... information wants to be free?
So you think information wants to be free is a strawman attacking people who are against DRM? Nah, doesn't make any sense at all.
You could trim your toenails with an axe - but it is not the best way to get the job done. It's slow. It's clunky. Animation and effects aren't synced properly to updates. The battery life is terrible and anything to do the same but with less power would be a blessing. When Wayland comes out on MeeGo I'll try it.
Nah, I reckon the posts will be about how dumb people are that take made up numbers at face value. Zynga is not a public traded company and if you dig back through the links to the source then the five billion dollar figure is an estimate.