Re^3: Multi-core and the future

All of this sounds great. And by great, I mean: brilliant; fantastic; amazing; extraordinary; just what the doctor ordered. I intend no hint of 'faint praise' here. But...

Does any of this actually work? Anywhere?

Each time a new parrot comes out I dutifully download it and go in exploration of the infrastructure to support these constructs, and I come up short.

And every now and again I pop over to PDD 25 and look for changes, but rarely notice any. It still talks the talk of supporting every concurrency model known to man, and then some, but comes up way short of explaining how it's going to achieve this feat.

And that's essentially why I stopped following the P6 lists. There is an aweful lot of talk about what P6 will do. Discussion after excruciating discussion about almost irrelevant minutia of what perl 6 will do. But almost nothing, and fiery defence for there being nothing, when the question is asked: how will P6/Parrot pull this off. (Not to mention the now sad joke of "by Christmas" for the question: when.)

I want to believe. I really, really want to believe...

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^3: Multi-core and the future

Replies are listed 'Best First'.
Re^4: Multi-core and the future by moritz (Cardinal) on Aug 31, 2008 at 23:02 UTC
Actually audreyt did present a version of pugs once that parallelized meta operators, with measurable speed difference between single core and dual core (not quite a factor of 2, but somewhere around 1.7 iirc). I don't know if "mainstream" pugs does it, though. I agree that it's hard to keep faith, but recently something helped me a lot: I played with grammars in Rakudo, and found that 1) although they are still limited, they work quite well and 2) it's really easy to parse stuff for which you'd normally write a recursive descending parser. (And I'll blog about it later this week). Now I firmly believe that they will be one of the killer features of Perl 6, even if concurrency might turn out not to work as well as promised. I don't think that you'll see a working, usable Perl 6 level concurrency implementation within the next year, though.	[reply]
Re^5: Multi-core and the future by BrowserUk (Patriarch) on Sep 01, 2008 at 17:12 UTC
Actually audreyt did present a version of pugs once that parallelized meta operators,... Presumably, that leveraged the well-developed abilities of Concurrent Haskell? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^4: Multi-core and the future by jplindstrom (Monsignor) on Sep 01, 2008 at 12:55 UTC
It still talks the talk of supporting every concurrency model known to man And does it really need to? In the first release? Wouldn't it be better to keep it in mind so the design isn't completely closed to future concurrency changes, and get something out the door? I'm assuming not everything in Perl 6 can work perfectly in the first ever release, so there would be a scoped delivery plan for which features go in 6.0, 6.1, 6.2 ... anyway, wouldn't it? /J	[reply]
Re^5: Multi-core and the future by BrowserUk (Patriarch) on Sep 01, 2008 at 17:09 UTC
And does it really need to? In the first release? Personally, I think not. From my perspective PDD 25 reads like nobody could make up their mind which were important, so they opted for them all. However, I am very aware as I write, that Allison Randall is a seriously knowledgable person, and I may just be missing the point. The problem with making the choice of concurrency model for Parrot, is the ideal of being able to support the requirements of any dynamic high level language that might sit atop it. The really tough part about concurrency is that you cannot tack it on later with any prospect of useability or performance. It has to be accounted for in the design of every aspect of the low-level supporting infrastructure. There is no way around that. Memory management, garbage collection, IO infrastructure, even the right choice of underlying C-runtime libraries are critical to success. And all of those choices are compounded by: each concurrency model you attempt to support; each HLL that might utilise them in novel ways; And that's the crux of the nervous tremours I feel in my gut each time I read about what Perl 6 will do and what Parrot will support. I have expended a considerable amount thought and reading to trying to understand how to implement just one of the concurrency models mentioned, and I believe it to be extremely hard, but doable. But trying to support them all? Trying to design a garbage collector that can support all those models of concurrency, potentially concurrently with the requirement to be able to run (say) Ruby code from within Python code from within Perl code. Will that ever be doable? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks