Re^3: RFC: Implicit Parallelization Pragma

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.

Cheers - L~R

Comment on Re^3: RFC: Implicit Parallelization Pragma

Replies are listed 'Best First'.

Re^4: RFC: Implicit Parallelization Pragma
by hardburn (Abbot) on Jan 26, 2005 at 14:22 UTC

How about the Schwartzian as an example?

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

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.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
[d/l]


The stupid question is the question not asked
	PerlMonks