[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