Open MP (was: Coming IO features in Tango)

Ingo Oeser ioe-news at rameria.de
Fri Aug 17 03:52:16 PDT 2007


Sean Kelly wrote:

[Open MP, parallel foreach/loops]

I think an even better one would be discovery and marking
of const functions/bodies. These can be automatically parellelized.

If the delegate generated by the foreach loop body is discovered
as const and doesn't contain a break or continue, then it can be subject
to parallelization. 

Another idea would be that we have a new kind of iteration called map(),
which maps a sequence or number of sequences to a new one 
and is defined as seeing each element from the sequence(s) only once
in undefined order.

Then add the reduce() iteration, which gets a (sub)sequence and reduces it
to a scalar. The order is also undefined here.

The third nice addition would be filter(), which checks every item
of a sequence against a predicate and returns all items, where the predicate
is true.

Python (and other languages) have these nice opportunities for
parallelization. 

Open MP basically just demands these and some tunables. Loop invariant
marking and detection and some other stuff can be done by the compiler
and maybe the programmer for the hard cases using the invariant{} syntax
within a loop.

The difference between map/reduce/filter are the data flow dependencies.
- For map/filter the flow is completely independent. 
  We only need to collect the results into one container.

- For reduce we have tree like result collection to built the final scalar.
  Anything needing that scalar has to wait for the final one.

- For map we can append a dependend map/filter loop within the same
  thread independent of the others.

- For filter the flow is debatable (e.g. one can transparently rewrite
  filter as "map eventually to null" and remove that null later).

The basic problem is, that foreach is still to generic and doesn't 
properly communicate what the programmer really wants to say. Currently
he can express, map/filter/reduce/find and maybe more with it. Which is
nice for the lexer/parser but not good enough for the optimizer.

Best Regards

Ingo Oeser




More information about the Digitalmars-d mailing list