On 18/08/2011, at 20:22 , Alexander Kjeldaas wrote: > The Nehalem micro-architecture has made unaligned loads very cheap, as long > as they do not cross a cache line boundary. > > I am thinking that this makes it possible for ghc to use 40-bit pointers, and > generally use "packed" structure layout. This again should improve > performance by increasing the effective CPU cache size. > > Even given a packed structure layout, the memory allocator could be improved > to ensure that no object field will cross a cache line by moving the object a > few bytes in either direction. > > Comments? How hard-coded is the ghc object layout.
De-aligning objects would break dynamic pointer tagging. You'd need to show that any win from the de-aliginment would be better than the win from dynamic pointer tagging. When objects are aligned on, say, 4 byte boundaries, then the lowest two bits of the object addresses are zero. For object pointers, the GHC runtime stashes extra information in these bits, to encode whether or not the pointed-to object is a thunk, and what data constructor it might be. If you de-align objects then these bits can no longer be used to store extra information. This issue is separate from the use of 40 bit pointers though. Even if objects are aligned, you could still perhaps usefully de-align the internal fields. I'm not sure what the other tradeoffs would be... Ben. _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
