[Edinburgh-pm] parallel semantics in perl
Aaron Crane
perl at aaroncrane.co.uk
Mon Dec 13 16:38:30 PST 2010
Wim Vanderbauwhede <wim.vanderbauwhede at gmail.com> wrote:
> For example, whereas statements in a bare {...} block will be
> evaluated in parallel, a do {...} could mean sequential evaluation. A
> "foreach" in full could be parallel, a "for" sequential. Any
> ideas/suggestion about this, e.g. how would you indicate that "map"
> should be sequential, etc? I obviously don't want to add new
> constructs to Perl 5.
My initial inclination is to disagree with your premise: I think that,
for example, sequential map and parallel map are different enough that
they should have different names. In particular, I really dislike the
idea of giving `for` and `foreach` different semantics; that strikes
me as likely to yield really confusing code. (And I think that, of
the two of them, I'd naturally read `foreach` as being sequential
rather than parallel — exactly the opposite of what you suggest.)
Nonetheless, if you're set on that approach, perhaps a lexical pragma
would do you what you want. I haven't really worked out any details,
but something like this seems plausible:
{
use parallel qw<:all>;
my @out = map { pure_function($_) } @in;
no parallel qw<map>;
my @out2 = map { side_effecting_function($_) } @in2;
for (@in3) {
# This still happens in parallel
frob($_) if is_interesting($_);
}
}
The obvious problem with that is that putting just one sequential loop
or map into mostly-parallel code takes an annoying amount of
boilerplate. But it's possible to construe that as a feature —
additional encouragement for writing parallel code. Though, on the
gripping hand, anyone who wants lots of sequential maps can easily say
sub seqmap (&@) {
my $code = shift;
no parallel qw<map>;
return map &$code, @_;
}
Either way, I'll definitely be interested to see what you come up with
— sounds like an interesting project!
--
Aaron Crane ** http://aaroncrane.co.uk/
More information about the Edinburgh-pm
mailing list