4 ms·
x86_64 == more registers available than on i386 more registers == fewer spills For the average compiled program, fewer spills == faster. => Average programs
by bbb 17y ago
x86_64 == more registers available than on i386
more registers == fewer spills
For the average compiled program, fewer spills == faster.
=> Average programs run faster under x86_64.
- litewulf 17y agoI believe in practice register renaming (http://en.wikipedia.org/wiki/Register_renaming http://en.wikipedia.org/wiki/Register_renaming) largely negates the difference in performance. Notice the mention of some CPUs having MORE registers than are nameable in the instruction set. I am not a hardware engineer though, so YMMV.
- axod 17y agoAnd use about twice as much Ram. Personally I think 8 bytes for every single pointer seems wasteful for most programs.
- jrockway 17y ago4 extra bytes for a pointer is wasteful, but having an entire separate vector CPU just to make the windows transparent isn't?
- axod 17y agoDepends on what your bottleneck is. For me, it's usually been memory rather than CPU. I was using 64bit, then switched to 32bit and saw a gigantic improvement in mem usage. (See slicehost vs linode comparisons etc)
- chancho 17y agoYour argument refutes itself handedly because 32bit processes are limited to 4GB of address space. You've maxed out 1Gb now, how long before you max out 4Gb? Memory concerns are clearly the reason to go 64bit, the stuff about registers is icing on the cake. 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.
- gjm11 17y agoEvidence that it's really "about twice as much"? Much of what any given program stores will be things other than pointers. According to http://www.springerlink.com/content/h6803610u1124354/ 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.
- mhansen 17y agoYour program is much larger due to 64-bit pointers. 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.
- litewulf 17y agoThere are ways to use 32 bit pointers in 64 bit mode...
- jsonscripter 17y agoThat's like saying extending a road from 4 miles to 4 million miles makes your car go faster.
- roc 17y agoI think it's more like saying: replacing your car with a bus allows you to get more people to the destination more efficiently. 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.