C++: 64 bit performance vs. 32 bit
|
From: Andy Freeman on 14 Feb 2006 18:04 Andy Glew wrote: > > > If you want to add more architectural registers, add them to the L2 > > > PRF. > > > > Why should the register file hierarchy be architecturally visible? > > > It should not be. From the users' point of view, there should be just > "N" registers of different types. The user should not care about > microarchitecture. Are these "different types" architecturally visible? That is, are these "more architectural registers" necessarily a new type, with different operations, or are they just more of some existing type?
From: Eliot Miranda on 3 Mar 2006 16:20 schouwla(a)yahoo.com wrote: > All, > > > Does anyone know how much performance speedup I can expect by using 64 > bit C++ / Windows XP 64 bit over the 32 bit versions? Derpends on the application. For a symbolic application (e.g. graph traveral) that doesn't fit in cache the 64-bit implementation should tend towards being twice as slow as the 32-bit implementation since the 64-bit version has to read twice the data, and the limiting factor is memory bandwidth. > Did anyone test this under Visual Studio 2005 or Intel C++ 8.1/9.0 ? Depending on processor, x86-64 being good, SPARC being poor, my 64-bit Smalltalk implementation is from 15% to 25% slower than the 32-bit one it shares a code base with. A typical Smalltalk image is about 50% byte data, 50% symbolic data so the application footprint grows by 50%. But a typical Smalltalk app will spend more than 50% of its time doing symbolic computation. The additional width allows one to play representation tricks to claw back performance. So one ends up with better performance than one might expect. But apart from specifics like faster floating-point due to an immediate floating-point datatype, in general the 64-bit implementation is slower. However, that's entirely irrelevant to users who need toi process datasets that don't fit in the 32-bit address space. For them 64-bits provide much higher performance than hand-rolled paging of the dataset, and more importantly much lower implementation costs. > > My application domain is montecarlo simulations but any test would be > great. The numeric part should speed-up. Processing of the data model, if large, should slow down, but if it fits in cache should remain the same. > > > Regards > Lars Schouw > -- _______________,,,^..^,,,____________________________ Eliot Miranda Smalltalk - Scene not herd
From: George N. White III on 3 Mar 2006 18:55 On Fri, 3 Mar 2006, Eliot Miranda wrote: > schouwla(a)yahoo.com wrote: > >> Does anyone know how much performance speedup I can expect by using 64 >> bit C++ / Windows XP 64 bit over the 32 bit versions? > > Derpends on the application. For a symbolic application (e.g. graph > traveral) that doesn't fit in cache the 64-bit implementation should tend > towards being twice as slow as the 32-bit implementation since the 64-bit > version has to read twice the data, and the limiting factor is memory > bandwidth. Is there a middle ground between 32-bit WinXP apps and 64-bit WinXP 64? On SGI Octanes you could use "-n32 -mips4" compiler flags to get 32-bit ints and pointers while still using R10k instructions. For the majority of apps that could live with 32-bits this was the best choice. -- George N. White III <aa056(a)chebucto.ns.ca>
From: Patrick Schaaf on 4 Mar 2006 01:37 "George N. White III" <aa056(a)chebucto.ns.ca> writes: >Is there a middle ground between 32-bit WinXP apps and 64-bit WinXP 64? >On SGI Octanes you could use "-n32 -mips4" compiler flags to get 32-bit >ints and pointers while still using R10k instructions. For the majority >of apps that could live with 32-bits this was the best choice. Is that not what WinXP 64 does? It is, as far as I know, what the ABI and compilers for x86-64 Linux (oder Unix?) do. 32-bit int, unless called 'unsigned long long', and 64-bit pointers. best regards Patrick
From: Anton Ertl on 4 Mar 2006 04:22
mailer-daemon(a)bof.de (Patrick Schaaf) writes: >"George N. White III" <aa056(a)chebucto.ns.ca> writes: > >>Is there a middle ground between 32-bit WinXP apps and 64-bit WinXP 64? >>On SGI Octanes you could use "-n32 -mips4" compiler flags to get 32-bit >>ints and pointers while still using R10k instructions. For the majority >>of apps that could live with 32-bits this was the best choice. > >Is that not what WinXP 64 does? It is, as far as I know, what the >ABI and compilers for x86-64 Linux (oder Unix?) do. No, he meant an ILP32 model running in AMD64 long (64-bit) mode. The 64-bit Windows has an IL32P64 model, and nearly all "64-bit" ABIs for various Unices on various architectures have an I32LP64 model, including Linux on AMD64. > 32-bit int, >unless called 'unsigned long long', and 64-bit pointers. "signed long long"s are at least 64-bit on every platform I have encountered, and longs (signed and unsigned) are 64-bit on "64-bit" Unices. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html |