#10652: Better cache performance in Array# -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MikeIzbicki): Replying to [comment:3 carter]:
Mike: have you looked at how the gc arranges values only reachable via a boxed array?
I guess one problem I can think of off hand is that your primops get
A valid and interesting idea would be to just make sure that the gc
I wouldn't even know where to look for this. My only evidence that things aren't aligned is the huge number of cache misses I'm getting. But I suppose these cache misses could be caused by something else. tricky when a value is shared across Multiple boxed arrays! My proposal doesn't run into this problem. I'm specifically not proposing that GHC try to find a "globally optimal" memory allocation scheme. Instead, all I want is that immediately after these operations are called memory is aligned. A subsequent call to these primops on another array with the same elements in a different order would destroy that alignment. places unshared values reachable only via a boxed array continuously when doing a copying gc. I should try to look into this myself. I think this would work for me, and probably be better in general performance-wise. I was just (maybe naively) imagining this would be harder to implement. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10652#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler