C++: 64 bit performance vs. 32 bit
|
From: Casper H.S. Dik on 4 Mar 2006 04:45 anton(a)mips.complang.tuwien.ac.at (Anton Ertl) writes: >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. I don't think there's such a model available in any OS (ILP32 in 64 bit AMD). You could construct one, but there's no automatic address truncation in the AMD64 long mode, so you will have to do pointer masking yourself (or have the OS take care of the traps) Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: Anton Ertl on 4 Mar 2006 13:28 Casper H.S. Dik <Casper.Dik(a)Sun.COM> writes: >I don't think there's such a model available in any OS (ILP32 in 64 bit AMD). Well, apart from the ability to run IA-32 binaries in compatibility mode (and the other mode I meant is called "64-bit mode"; "long mode" encompasses these two modes). My guess was that this was not done because they did not want to provide a third set of libraries (in addition to IA-32 and I32LP64 support) and 32-bit support in 64-bit mode system calls, but apparently you see additional reasons: >You could construct one, but there's no automatic address truncation >in the AMD64 long mode, so you will have to do pointer masking yourself >(or have the OS take care of the traps) What problems do you see? IIRC AMD64 always zero-extends 32-bit operations. In what cases would pointer masking be needed? My guess is that it would be pretty rare. - 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
From: Stephen Sprunk on 4 Mar 2006 22:13 "Anton Ertl" <anton(a)mips.complang.tuwien.ac.at> wrote in message news:2006Mar4.192855(a)mips.complang.tuwien.ac.at... > Casper H.S. Dik <Casper.Dik(a)Sun.COM> writes: >>You could construct one, but there's no automatic address truncation >>in the AMD64 long mode, so you will have to do pointer masking yourself >>(or have the OS take care of the traps) > > What problems do you see? IIRC AMD64 always zero-extends 32-bit > operations. In what cases would pointer masking be needed? My guess > is that it would be pretty rare. There is no guarantee that any given pointer returned by malloc() or any syscalls is guaranteed to be in the 32-bit address space. It's simply not safe to use 32-bit pointers in 64-bit mode unless you first check the value to see if the high bits are zero and have some way to map the corresponding memory down into the 32-bit range. That'd be a mess. A perverse implementation might, for various reasons, decide that userland begins at 2^32. The current Linux AMD64 ABI, IIRC, requires all user code to be in the first 2GB (and the kernel in 0 to -2GB), so it might make programs more deterministic to start the heap at a fixed value that can't possibly conflict with code. While the specific workload does cause variations, the cache effects of 64-bit pointers are usually more than offset by the performance gained by having eight extra GPRs. Slower cache, but less need to use it. S -- Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin *** Free account sponsored by SecureIX.com *** *** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
From: Greg Lindahl on 5 Mar 2006 01:07 In article <440a588b$0$1101$6d36acad(a)titian.nntpserver.com>, Stephen Sprunk <stephen(a)sprunk.org> wrote: >There is no guarantee that any given pointer returned by malloc() or any >syscalls is guaranteed to be in the 32-bit address space. Systems for which this is guaranteed: -n32 on MIPS -taso on Alpha There's also a funky 32-bit-where-possible mode in the Intel compiler for both x86_64 and ia64. You are correct that you can't randomly assume you can do this. But it's not hard to arrange if you control enough pieces of the system. -- greg
From: Anton Ertl on 5 Mar 2006 03:42
"Stephen Sprunk" <stephen(a)sprunk.org> writes: >There is no guarantee that any given pointer returned by malloc() or any >syscalls is guaranteed to be in the 32-bit address space. Yes, one would have to extend a few system calls (those that allocate address space) with a 32-bit flag (or have 32-bit variants of these system calls); malloc() only gets its memory from system calls. As Greg Lindahl wrote, this has been done in many OSs (and the IA-32 (compatibility mode) support in AMD64 long mode OSs requires much more effort). But my question was this: in which cases would the compiler have to use more instructions for ILP32 programs in 64-bit mode than for I32LP64 programs? >While the specific workload does cause variations, the cache effects of >64-bit pointers are usually more than offset by the performance gained by >having eight extra GPRs. In 64-bit mode, the compiler can use these GPRs (as well as the 8 extra XMM registers). >Slower cache, but less need to use it. Sounds like a fallacy to me. The cache accesses that the additional registers avoid would all be cache hits. The cache misses that the bigger pointers cause are not reduced by having more registers. - 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 |