> But in the worst case its just a sequential computation, so any gain from > 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 / multi-core environments: - 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). Cheers, Tim _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
