On Fri, May 14, 2010 at 09:50:21AM -0700, Larry Wall wrote: > On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
...<snip> > > 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. The future is indeed multicore - or, rather, *many-core. What this means is that however the hardware jockeys have to strap them together on a single node, we'll be looking at the ability to invoke hundreds (or thousands) of threads on a single SMP machine. Then, inevitably, *someone will want to strap these together into a cluster, thus making message passing an attractive way to glue related threads together over a network. Getting back to the availability of many threads on a single SMP box, issues of data locality and affinity and thread binding will become of critical importance. These issues are closely related to the operating system's capabilities and paging policies, but eventually (hopefully) current, provably beneficial strategies will be available on most platforms. Brett > > 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 -- B. Estrade <estr...@gmail.com>
