One of the downsides of a 64-bit environment is the increased size of pointers. This means that the cost of a String increases from something like 12 bytes per char to something like 24. I notice BEA uses something called "compressed pointers" to get the 64-bit (more registers, etc) benefits without paying the (cache-thrashing) cost. http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp107976... Something for GHC? -k -- If I haven't seen further, it is by standing in the footprints of giants
On Apr 16, 2008, at 4:45 AM, Ketil Malde wrote:
I notice BEA uses something called "compressed pointers" to get the 64-bit (more registers, etc) benefits without paying the (cache-thrashing) cost.
But only if you're not *actually* using a 64-bit address space. From their own documentation: The heap size will be limited to less than 4 GB; therefore, you can only use this option for applications that demand less than 4 GB of live data. The heap will be reduced to meet this size limitation if you specify a larger initial (-Xms) or maximum (-Xmx) heap size. (http://edocs.bea.com/jrockit/jrdocs/refman/optionXX.html#wp1021022) So this amounts to saying "we can use the 64-bit ISA but still use 32- bit pointers with all the restrictions that accompany them". You might be able to keep non-heap data around in excess of 4GB (eg it might be possible to mmap a file *and* have 4GB of heap data, and maybe even keep thread stacks off-heap as well). You can take advantage of pointer alignment to get address spaces of 8-32GB (by shifting 32-bit pointers before dereferencing them), but that requires taking back the pointer bits that GHC just stole for pointer tagging. -Jan
ketil:
One of the downsides of a 64-bit environment is the increased size of pointers. This means that the cost of a String increases from something like 12 bytes per char to something like 24.
I notice BEA uses something called "compressed pointers" to get the 64-bit (more registers, etc) benefits without paying the (cache-thrashing) cost.
http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp107976...
Something for GHC?
One small upside (performance wise), is that the bottom 3 bits of the pointer are now used to encode the constructor on 64 bits, so 'case' gets a good percent cheaper. -- Don
Don Stewart
One small upside (performance wise), is that the bottom 3 bits of the pointer are now used to encode the constructor on 64 bits, so 'case' gets a good percent cheaper.
Well - my experience (which is from before this optimization was added, I think) is that 64bit Haskell is slower than 32bit Haskell. Anyway, I think this is an orthogonal issue - by limiting your program to 4GB RAM, 4-byte alignment could give you two bits for pointer tagging and 32 bit pointers. If you still do 8-byte alignment, there's no difference. In extremis, you could imagine several different models based on heap size, with optimal choices for pointer size, alignment and tag bits. If you shift the pointer, you could address up to 16G from 32 bits (by using 8-byte alignment and one tag bit). This probably becomes too complicated, but I thought it was interesting that the Java people are making use of 32bit pointers on a 64bit system, and are seeing a good performance benefit from it. -k -- If I haven't seen further, it is by standing in the footprints of giants
Hello Ketil, Friday, April 18, 2008, 10:44:53 AM, you wrote:
This probably becomes too complicated, but I thought it was interesting that the Java people are making use of 32bit pointers on a 64bit system, and are seeing a good performance benefit from it.
afaik, C compilers support this model too, so it shouldn't too hard to compile GHC in such mode. it's a bit like small/large memory models of those 16-bit x86 systems :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Ketil,
Friday, April 18, 2008, 10:44:53 AM, you wrote:
This probably becomes too complicated, but I thought it was interesting that the Java people are making use of 32bit pointers on a 64bit system, and are seeing a good performance benefit from it.
afaik, C compilers support this model too, so it shouldn't too hard to compile GHC in such mode. it's a bit like small/large memory models of those 16-bit x86 systems :)
Except that you'd need to compile all your libraries in that mode too. The reason Java can do this is I imagine because they JIT all the code at runtime so they can change some aspects of code-generation strategy without recompiling everything. Cheers, Simon
jhc packs data into pointers when possible. so for instance data Foo = Foo !Word16 !Word32 gets encoded as ------------------------------- | 16 bits | 32 bits | ... | 10| ------------------------------- This particularly helps strings, where the character can often be encoded in the space of the pointer itself. (even on 32 bit architecturs, as Char is only 24 bits in jhc) John -- John Meacham - ⑆repetae.net⑆john⑈
participants (6)
-
Bulat Ziganshin -
Don Stewart -
Jan-Willem Maessen -
John Meacham -
Ketil Malde -
Simon Marlow