Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
The preinstalled OS is not even using 64-bit modeThe preinstalled OS is not even using 64-bit modePosted Feb 21, 2007 0:16 UTC (Wed) by mikov (subscriber, #33179)In reply to: The preinstalled OS is not even using 64-bit mode by cwitty Parent article: Dell users demand more Linux options (ZDNet UK)
Most benchmarks do not confirm this. I believe it has been shown that for apps which are not constrained by virtual memory space, going to 64GB offers very little improvement, if any at all. Don't forget that making all pointers 64-bit increases memory and cache pressure significantly. At least one 64-bit Java VM implements "pointer compression" - when possible using 32-bit pointers even in a 64-bit application. The existence of such complex solutions and the fact that they are actually beneficial illustrates the severity of the problem.
Bottom line, unless you _really_ need 64-bit, you are much better off with 32-bit, even on a 64-bit CPU.
(Log in to post comments)
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 1:47 UTC (Wed) by dlang (subscriber, #313) [Link] I've seen speedups when switching to 64 bits, even with <4g
like all benchmarks, your mileage may vary.
if your task is primary moving data around then the fact that you have more data to move around makes it a loss.
if you are compute bound then the increase in registers can make a huge difference.
java is far from the most efficiant system available, so don't take it's performance as representing everything ;-)
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 18:03 UTC (Wed) by mikov (subscriber, #33179) [Link] I did a quick trawl through the Spec database to compare 32-bit and 64-bit results of the same system. There aren't that many, but here are a couple I found (the first ones in the output sorted by system name).
I am looking at the baseline results, because they are much more representative for typical non-benchmark apps.
32-bit: 1666 http://www.spec.org/osg/cpu2000/results/res2006q1/cpu2000...
32-bit: 1831 http://www.spec.org/osg/cpu2000/results/res2006q4/cpu2000...
32-bit: 1688 http://www.spec.org/osg/cpu2000/results/res2006q1/cpu2000...
It is interesting that the peak results usually reverse the situation, making the 64-bit faster. Also, different compilers are being used for 32-bit and 64-bit, but this is the closest to a comparison I could find.
Basically, no matter how you look at it, 64-bit doesn't seem to offer significant performance advantage, even if I would not call it slower.
About Java's slowness: I was using that as an example for the benefit of pointer compression. Obviously it can't be tested in a native environment. The point is that its benefits are measurable, and consequently the slowdoan from 64-bits is not negligible.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 3:25 UTC (Wed) by rafdz (guest, #41427) [Link] i think that pointer compression should be used even on 32 bits by compressing pointers to 16 bits or even 8 bits.i don't think that this is that complicated, one could simply implement custom allocators with memory areas of say 256 Kbytes (64K words ) or 512Kbytes.i think that neither gcc nor linux kernel should use 64 bits pointers in general(they should be used only in some specific cases).switching to compressed pointers would take some efforts, but it's the only way to fully exploit current hardware capabilities.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 18:32 UTC (Wed) by RareCactus (guest, #41198) [Link] Hardware is a moving target.
No doubt in a few years, 64-bit pointers will be the norm, and 32-bit pointers will be supported the same way real-mode applications are in Windows-- poorly, and slowly through emulation.
Using 16-bit pointers (which is only possible in real mode) is already a huge performance hit. The chip designers support it, but they don't care how fast it is, because most people only ever are in this mode when they're looking at the BIOS.
I don't understand what you're talking about with 8-bit pointers, since the x86 has never had those.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 7:33 UTC (Wed) by k8to (subscriber, #15413) [Link] On the 10-20 real-world performance-limited applications I've tested, the amd64 compiled code is 5-20% faster. Mostly these are silly things like compresion software, codecs, emulators and so on. But I've seen basically 0 cases where the performance is equivalent.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 18:14 UTC (Wed) by mikov (subscriber, #33179) [Link] I don't have any hard data, but see my reply to dlang above in this thread with a couple of references to SPEC2k results (which are debatable). I also remember reading about a benchmark of a 64-bit and 32-bit game on Windows where the 64-bit build was slower, so it was concluded that game developers have absolutely no incentive of testing and releasing 64-bit builds (considering WOW64). Alas, I can't find the link :-(
As far as I can tell, a typical desktop user would not see in any noticable performance difference between 32 and 64 bit, so the trouble of going to 64-bit is usually not worth it for them.
For CPU-bound stuff like codecs and compression, it sure seems that the improvement should be significant - they use little pointers, so there should be no disadvantage of 64-bits. However if you take any Java app, it has lots and lots of pointers, so it will suffer greatly. Which is ironic, because Java is supposed to be good for servers, and precisely servers are switching to 64 bit .. :-)
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 20:11 UTC (Wed) by rafdz (guest, #41427) [Link] i admit that using 8 bits pointers is not realistic.however 16 bits pointers i am talking about are not real pointers.they are in fact indexes that must added to a base 64 bits or 32 bits real pointers.the pointer compression methdo is explained in the following paper.http://llvm.org/pubs/2005-06-12-MSP-PointerComp.ps. according to that paper pointer compression is beneficial only when working set of program doesn't fit into L2 cache.on other papers it has also been proved that automatically transforming memory heap allocation into automatic pool allocation could also improbe locality and hence improve performance.it would be nice if gcc could integrate the two approaches (pointer compression and automatic pool allocation) but this obviously will require a lot of research and hard work before it will be possible.
|
|||||||||||