John Meacham wrote:
On Tue, Nov 25, 2008 at 09:39:35PM +0100, Ketil Malde wrote:
This corresponds to my experiences - 64 bits is slower, something I've ascribed to the cost of increased pointer size.
ghc unfortunatly also uses 64 bit integers when in 64 bit mode, so the cost paid is increased due to that as well, Also since each math instruction needs an extra byte telling it to work on 64 bit data so the code is less dense.
Right - in the Java world they use tricks to keep pointers down to 32-bits on a 64-bit platform, e.g. by shifting pointers by a couple of bits (giving you access to 16Gb). There are a number of problems with doing this in GHC, though: - we already use those low pointer bits for encoding tag information. So perhaps we could take only one bit, giving you access to 8Gb, and lose one tag bit. - it means recompiling *everything*. It's a complete new way, so you have to make the decision to do this once and for all, or build all your libraries + RTS twice. In JITed languages they can make the choice at runtime, which makes it much easier. - it tends to be a bit platform-specific, because you need a base address in the address space for your 16Gb of memory, and different platforms lay out the address space differently. The nice thing about GHC's memory manager is that it currently has *no* dependencies on address-space layout (except in the ELF64 dynamic linker... sigh). - as usual with code-generation knobs, it multiplies the testing surface, which is something we're quite sensitive to (our surface is already on the verge of being larger than we can cope with given our resources). So my current take on this is that it isn't worth it just to get access to more memory and slightly improved performance. However, perhaps we should work on making it easier to use the 32-bit GHC on 64-bit platforms - IIRC right now you have to use something like -opta-m32 -optc-m32. Cheers, Simon