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. Larry
