Re: I386 V AMD64 Debian part 2
Thanks for the reply, it is apreciated. Russell Coker said,
The limit on per-process address space (which isn't just a limit on memory use) is the main thing. Also there are performance issues with PAE.
The problem with claims of performance differences is that an awefull lot of things can effect this and I have only seen one report (of 32 v 64 bit) giving full details and test results of said tests. These showed some things were faster and some were not. There are plenty of sites claiming performance enhancements of 64 bit, almost none (only a single site) gives any real evidence, most sites __clearly__ cherry picking data. This sort of thing makes me __very__ sceptical as if something really is faster one will see benchmarks published all over the place.
Have you enabled multi-arch?
Yes, the last remaining problem is getting the closed src driver working everything I have tried so far leads to the same thing. The X server crashing after start up from a memory violation to do with a font library. This is also with Debian Stable AND sid, four different kernels, two of Debian's the others my own and of course two differnt vserions of xorg. I am going to try i386 to see what will happen, I may add I have never had the current graphics card an NVidia GTX 680 working on a closed src driver under linux, works __mostly__ great under the open src driver. The card works great under Windows XP. Lindsay
On Sat, 2 Nov 2013, zlinw@mcmedia.com.au wrote:
Russell Coker said,
The limit on per-process address space (which isn't just a limit on memory use) is the main thing. Also there are performance issues with PAE.
The problem with claims of performance differences is that an awefull lot of things can effect this and I have only seen one report (of 32 v 64 bit) giving full details and test results of said tests. These showed some things were faster and some were not. There are plenty of sites claiming performance enhancements of 64 bit, almost none (only a single site) gives any real evidence, most sites __clearly__ cherry picking data. This sort of thing makes me __very__ sceptical as if something really is faster one will see benchmarks published all over the place.
Some years ago I compared the performance of 32bit and 64bit builds of gzip on an Opteron system and found that the 32bit version was faster. The difference was about 20% from memory and that was when running an AMD64 kernel. As there are some ways in which non-PAE i386 kernel code can outperform AMD64 kernel code (due to more efficient cache and TLB use) an i386 kernel with 32bit gzip would have an even more significant benefit over the AMD64 gzip on that hardware. I believe that the performance benefit was entirely due to the i386 assembly code in the gzip source - maybe nowadays there is equivalent AMD64 assembly code and/or better gcc optimisations for AMD64. But generally you expect some benefits. The lack of certain i386 register- saving optimisations means less self-modifying code and better system security (I provided links to my blog posts on this topic earlier in this thread). The larger number of registers and native 64bit computation gives significant performance benefits for some operations. I think that the thing to consider is the size of the performance difference and the number of operations that it applies to. 20% performance boost for gzip isn't a big deal as gzip usually isn't a critical performance thing. A 5% performance benefit from using a i386 kernel instead of an AMD64 kernel (as some of the early benchmarks showed) probably isn't a big deal as 5% isn't that much. The benefit from using 64bit math or memory mapping >4G of data can be very significant and the benefit of more registers applies to most programs. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (2)
-
Russell Coker -
zlinw＠mcmedia.com.au