| |||||||||||||
|
| |||||||||||||
My kid hates Linux (ZDNet)My kid hates Linux (ZDNet)Posted Apr 14, 2008 23:47 UTC (Mon) by djabsolut (guest, #12799)In reply to: My kid hates Linux (ZDNet) by pizza Parent article: My kid hates Linux (ZDNet)
Not to disparage the generally good idea of moving towards x86_64, however an improvement of 11% is not really worth the hassle of incompatabilities. What are the speedups like on average ? (AFAIK, modern processors "translate" the crufty x86_32 code into their own internal code, and along with a large cache this makes issues such as lack of registers not really a problem. The only practical reason one would want to use x86_64 is larger available memory space and/or 64 bit math -- the number of applications needing this is dwarfed by plain-jane applications).
(Log in to post comments)
My kid hates Linux (ZDNet) Posted Apr 15, 2008 3:44 UTC (Tue) by jwb (guest, #15467) [Link] There are major differences with x86_64 that show up everywhere, not just for math. The calling convention on the 64-bit system are far cleaner. More arguments can be passed to functions in the registers (6, I think) than on 32-bit systems, where the extra arguments have to be placed on the stack. Stack management function on x86 are not free; they take one or a few cycles during every function call and function return. This can add up. x86_64 also allows more and better ways of addressing data that can save an explicit load to register. These are not theoretical improvements. Lots of programs run much better on x86_64 than on plain old x86. The 64-bit systems do still have the problem of larger pointers which can crowd the cache, but some programmers find ways around this. BEA, for example, uses short heap pointers in their JVM, which gives them all the speedups of the x86_64 programming model (described above) without paying the cost of 64-bit pointers.
|
|
||||||||||||