Ouch.
In general there's way too much fanboyishness in this article. I mean, seriously, it closes on a note of, "You can't see any improvements so JUST IMAGINE how much they've done under the hood!"
Ouch.
In general there's way too much fanboyishness in this article. I mean, seriously, it closes on a note of, "You can't see any improvements so JUST IMAGINE how much they've done under the hood!"
more registers == fewer spills
For the average compiled program, fewer spills == faster.
=> Average programs run faster under x86_64.
The big speed drops will occur with cache misses. Your L1 and L2 cache are only so big, and every cache miss will set you speed back about an order of magnitude.
I am not a hardware engineer though, so YMMV.
Look at the big picture, whether it be pointers or integers into an array: the size of the index grows with the log of the number of things being indexed. You can't avoid this growth, but it matters less and less as you grow.
According to http://www.springerlink.com/content/h6803610u1124354/ (actual article is behind a paywall; but the information I'm referring to is on the first page, which is shown) the typical increase in size for Java objects is 40%. I strongly suspect that most programs that use a lot of memory (which are the ones that matter) do so because they have big wodges of non-pointer data (long strings, images, matrices, ...) and therefore get a smaller-than-average size increase, but I have no actual evidence for this.
Anyway, you'd only get a 2x increase if every single byte of memory used by your program were either a pointer or an integer that changed from 32 to 64 bits on switching to 64-bit code (e.g., a long in C or C++, for gcc at least). That's gotta be far from the truth.
It's true -- if you have more people than the car could hold. If you don't, the added overhead of using a bus will cause a comparative loss of overall performance.
This is a good start:
http://en.wikipedia.org/wiki/64-bit#Architectural_implicatio...
The most obvious improvement is that 64-bit programs can address more memory -- more than 4 gigabytes of virtual memory in the same process. The less obvious bit that sometimes makes things faster is that when an x86_64 CPU is running in 64-bit mode it has access to more registers (basically the ultra-mega-low-latency memory for numbers and memory addresses and stuff that everything computed must pass through).
However, since pointers to blocks of memory are twice as large on 64-bit programs and many programs use lots of them, 64-bit programs usually use more memory, which means that there are more cache (the slightly less, but still ultra-low-latency memory that's between the registers and usual memory) "misses" -- i.e. things have to be grabbed more often from main memory, which relative to registers and cache is slow ... meaning that it eats some of the performance benefits of the extra registers.
In a nutshell, 64-bit programs are different. They're not "faster". The difference in bit-width really isn't something that makes a lot of sense if you don't know how CPUs work and can't be reduced to "faster".