[Haskell] Implicit parallel functional programming
tharris at microsoft.com
Thu Jan 20 06:43:46 EST 2005
> But in the worst case its just a sequential computation, so any gain
> parallelism is still a gain...
The trade-offs involved look like they'd be very complicated in
practice. For instance, considering speculative execution on SMT /
- The mechanisms used to enable parallel evaluation may add direct
costs to straight line code -- e.g. I'd hope there's no need for "real"
locking in fast paths, but what's the cost in terms of interlocked
instructions and memory barriers?
- The execution of speculative threads on other cores may add indirect
costs by causing extra cache misses in mainline threads.
- Incorrectly speculated execution may still produce garbage; how much
of this can we keep processor-local? Do traditional parallel GC
techniques handle this well, or do we need better support for
generally-thread-local heaps and something that looks more like
distributed GC between them (or Ln-cache-local for some value of n)?
- The sharing between cores / threads is likely to be non-trivial --
e.g. no point using two hyperthreads to execute memory-bound operations
on the same core if the memory bus to that core is saturated (James
Bulpin's thesis from cl.cam.ac.uk has some stats from SPEC benchmarks
and discusses some of the scheduling problems).
More information about the Haskell