Re^3: RFC: Implicit Parallelization Pragma

[Limbic~Region]

hardburn,
Might I suggest you use a different example then. I didn't think you were proposing FIFO, but the example seemed that way to me. Additionally, I think having a second more constrained version that did guarantee order would still be useful. Imagine the following project:

• Get the length of all words in the list
• Look each word up in a dictionary
• Count the number of syllables in a word

Now for the sake of argument, looking each word up in the dictionary takes twice as long as both getting the length of the word and counting the number of syllables together. If these 3 tasks were done in parallel, it should take only roughly the same time as just looking up each word. On the other hand, if the order isn't guaranteed - the results coming out might not be very useful.

In other words, the elapsed time becomes close to the length for the longest pole in the tent. Some time is also spent ordering the results as they become available. Of course, I may be way out in left field here.

[hardburn]

How about the Schwartzian as an example?

my @sorted = 
    map   { $_->[0] }
    sort  { $a->[1] <=> $b->[1] }
    map   {[ $_, substr( $_, 2, 5 ) ]} @list;

The maps can be parellelized, and the sort can, too, if perl (lowercase) implemented it with a parellel sorting algorithm. The second map (in execution order) must come out in correct order--otherwise, why did you even bother sorting? Intrestingly, the first map does not need to come out in order, though there is a problem of letting perl in on this fact.