[racket] OS threads, parallel-map, etc.

On 05/31/2011 09:52 AM, Erich Rast wrote:
> Recently I started to wonder why Racket has futures and now also places
> but so far lacks traditional OS-level threads and parallel-map,
> parallel-for-each, parallel-sort, parallel-filter, for/parallel and the
> likes for sequences.
Places is an abstraction over OS-level threads (they provide 
parallelism), but they are not like traditional OS-level threads.

Traditional OS-level threads require extensive locking in the run time 
which is extremely difficult to implement correctly.  Locks also 
serialize execution and can slow down sequential performance of the 
runtime.

parallel-for-each, parallel-sort, parallel-filter, for/parallel and the
likes for sequences.

Theses are next on our radar.  Implementing these generically is more 
difficult than it sounds.  I would venture to say that most sequences 
are too short to see performance gains from parallel operations.

On the other hand, long sequences with significant computation is the 
sweet spot for parallelism.

>
> It seems to me that such sequence functions could even choose their
> optimal implementation automatically based on the number of available
> cores (and perhaps also generic benchmarks/heuristics). I've taken a
> look at my code and have found practically no examples where a parallel
> version wouldn't work because of order or side-effects; so using
> parallel sequence traversals could be an easy "find&replace" way to
> speed things up a bit. AFAIK, these functions cannot be implemented in
> general on the basis of futures because of the (sort of mysterious)
> fast/slow path distinction, right?
>
> Is there a problem with the GC or what else is the reason why these
> operations are not available? Are they planned for the future?
The GC does make parallel implementations more difficult but not impossible.
>
> It's not a criticism...I'm happy with Racket as is, just asking out of
> curiosity.
>
Thanks for the good questions!  Your wishes/requests are definitely 
valid.  Higher level parallelism constructs for users is our next 
priority, now that places are pretty stable.


Kevin
> Best,
>
>
> Erich
>
> _________________________________________________
>    For list-related administrative tasks:
>    http://lists.racket-lang.org/listinfo/users