Ticket #4167 (closed feature request: fixed)

Opened 20 months ago

Last modified 19 months ago

Add numSparks# to return the number of elements in the current capability's spark queue

Reported by: ekmett Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.12.3
Keywords: Cc: ekmett@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

Adding

numSparks# :: State# s -> (# State# s, Int# #) 

returning

dequeElements(cap->spark) 

from the c-- backend would permit user code in Haskell to inspect the current capability's spark backlog to decide whether or not to spark a task at all.

Consider how the following combinator from 'speculation' works. Under load, the par will cause the speculation to be discarded, but otherwise it can use it to begin evaluating the function before the argument a is ready, enhancing parallelism if the guess is accurate.

spec :: Eq a => a -> (a -> b) -> a -> b
spec guess f a =
    speculation `par`
        if guess == a
        then speculation
        else f a
    where
        speculation = f guess

Under high load:

foreground: [----- a -----]
foreground:               [-]               (check g == a)
foreground:                 [---- f a ----]
overall:    [-------- spec g f a ---------]

However, a similar combinator needs must degrade much worse under load.

specSTM :: Eq a => a -> (a -> STM b) -> a -> STM b

Due to the fact that the computation of the function is an STM calculation that needs access to the current transaction, it can't be moved into the spark. However, it *could* inspect numSparks# to determine if the current capability's spark queue was loaded and therefore would backlog anyways to avoid evaluating f g at all under load, allowing it to (somewhat clumsily) ape the graceful degradation under load experienced by spec.

This unfortunately cannot be done directly in a third party package using foreign import prim because the capability and spark queue are declared private and so GHC's codebase is the only place that has access to the appropriate primitives.

For more timelines and examples, see 'speculation'.

Change History

Changed 20 months ago by ekmett

  • cc ekmett@… added

Changed 19 months ago by simonpj

This numSparks# idea would allow us to implement the "split when hungry" idea of Rainey et al; see "Lazy tree splitting", ICFP 2010.

Changed 19 months ago by simonmar

  • status changed from new to closed
  • resolution set to fixed

Done:

Tue Jul 20 16:37:46 BST 2010  Simon Marlow <marlowsd@gmail.com>
  * add numSparks# primop (#4167)

and libraries/base:

Tue Jul 20 16:38:58 BST 2010  Simon Marlow <marlowsd@gmail.com>
  * add numSparks :: IO Int (#4167)
Note: See TracTickets for help on using tickets.