http://qs1969.pair.com?node_id=708202


in reply to Re^3: Multi-core and the future
in thread Multi-core and the future

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

Replies are listed 'Best First'.
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.