[GHC] #5925: Add inline version of newArray#
GHC
ghc-devs at haskell.org
Thu Mar 6 23:44:03 UTC 2014
#5925: Add inline version of newArray#
-------------------------------------+------------------------------------
Reporter: tibbe | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler | Version: 7.4.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By: 4258
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by jberryman):
Replying to [comment:12 tibbe]:
> ...So the task at this point is to come up with some good benchmarks.
There are essentially two ways to attack that problem. Either we can try
to show a speed-up in allocation or we can try to show a speed-up due to
the better locality (e.g. constructor wrapping an array can now be
allocated next to the array.)
I don't understand this issue very well, but I wonder if you'd see any
difference in running something like this through criterion:
{{{
do let payload = P.newArray 32 0 :: IO (P.MutableArray
(PrimState IO) Int)
x <- newEmptyMVar
y <- newEmptyMVar
forkIO $ (replicateM_ 500 payload) >> putMVar x ()
forkIO $ (replicateM_ 500 payload) >> putMVar y ()
-- ... etc, for number of cores - 1 or so
takeMVar x
takeMVar y
}}}
..using `payload = return ()` as the baseline measurement? Or maybe
microbenchmark newArray followed by a read?
Re. better locality, I have a real application: a Chan-like IORef linked
list of small `MutableArray`s. Maybe creating/traversing a structure like
that would show some improvement?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5925#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list