On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
: After reading this thread and S17, I have lots of questions and some
: remarks.
: Parallelism and Concurrency could be considered to be two different things.
: The hyperoperators and junctions imply, but do not require,
: parallelism. It is left for the implementors to resolve whether a
: single or multiple processor(s) is/are used. Hence, parallelism
: could be considered to be something under the hood of perl6 and not
: directly specified.

Certainly we've put in a number of abstract constructs that, if used by
the programmer, make promises of parallelizability, even if the the
implementation makes no promises about actual parallelization.

: Given that:
: - concurrency is a topic of ongoing research
: - several models of concurrency have been tried, including two in perl5
: - there are a variety of contexts (internet, clouds, multiple cores, etc)
: - different operating systems provide different resources
: then:
: How much needs to be specified and implemented in perl6 so that
: different concurrency models can be implemented in modules to take
: into account the above diversity?
: The less, or rather the more abstract, the specification in perl6,
: the less likely perl6 will 'age'.

Yes, but...

We need to understand the possibilities sufficiently well to provide a
default implementation that most modules can code to, or we'll simply
end up with a mess of incompatible modules.  This goes doubly for the
standard library; if it is written in a way that violates the
constraints of a thread model, it will not be useable under that model.
(See the Perl 5 ecosystem for what happens if you bolt on threading
after the fact.)

So what we're primarily trying to understand and predict is how the
various threading models will constrain us in our normal coding
patterns, and how we can make those constraints as invisible as
possible without either violating them by accident or inducing
unnecessary overhead.  Requiring the programmer to make a few minor
accomodations to achieve this may buy us a lot of non-grief in
the future.

But as you say, this is not a simple problem to solve; our response
should not be to punt this to future generations, but to solve it
as best as we can, and hope we can make some of the hard decisions
right enough to allow future evolution.

I am very glad to see several passionate but mostly-rational
people thrashing this out here; the future is many-core, and none
of us understand the implications of that well enough yet to write
off the topic as a bikeshed, or to wish for the good old days of
single core.  Sure, it should be possible to write a Perl program in
a single-threaded mindset, but while certain popular languages cling
to the past and try to make single-threadedness a feature, Perl is
more about embracing the future and about freeing the programmer from
arbitrary restrictions.  And as Perl 5 OO demonstrated, sometimes
not picking a good default can be just about as damaging as picking
the wrong one.

Note also that the fundamental difficulty with doing threading in
Perl 5 is not the exact model chosen, but rather that the fundamental
underpinnings of locality were (for various historical reasons)
poorly designed/evolved in the first place, so we ended up with far
too much information having to be managed outside of its proper scope,
for many different definitions of "scope".

This has been one of the secret sauces of the Perl 6 redesign, to
hang every piece of information on the peg where it belongs, and not
somewhere else.  And that is why threading of *any* kind will work
much better in Perl 6.


Reply via email to