in reply to Re^12: Backend diversity for Rakudo
in thread Backend diversity for Rakudo

Show me where I said: "Perl 6 hates concurrency and refuses to do anything about it!"...
... given the low priority, bordering on active hostility, towards concurrency, achieving the will to correct such problems is very unlikely.

BrowserUk, Re^8: Backend diversity for Rakudo

... or "it's too late for Perl 6 or Parrot to do anything sane with concurrency.".

BrowserUk, Re^6: Backend diversity for Rakudo

Do you consider those words constructive efforts to engender dialog?

Replies are listed 'Best First'.
Re^14: Backend diversity for Rakudo
by BrowserUk (Patriarch) on Aug 18, 2010 at 00:25 UTC

    Can you not see that: . given the low priority, bordering on active hostility, towards concurrency, achieving the will to correct such problems is very unlikely. is vastly different to: "Perl 6 hates concurrency and refuses to do anything about it!"...?

    Can you deny that only considering concurrency now, after 10 years of development, is: given the low priority,"?

    Do I need to dig out all the quotes from Perl Community leaders and one-time Parrot lead developers etc. saying stuff like "threads is spelt 'fork'"; and generally denying that threads are useful? Does that not constitute "bordering on active hostility"?

    Again you attribute quotes: "it's too late for Perl 6 or Parrot to do anything sane with concurrency.". not for things I said; but for your interpretation of what I said.

    For a start I was referring to Parrot alone--not Perl 6.

    But actually, I do believe it is too late to retro-fit threading to Parrot.

    One reason is: I don't believe you can ever achieve good performance using a register-based VM in a threaded environment. Each thread has its own stack, and that is where all thread local entities should live. Using a common heap for low-level interpreter entities (eg. register spill files), creates the need for too much locking.

    I don't believe that user-space threading is a viable solution to concurrency in the rapidly encroaching world of multi-core CPUs.

    Hence: "achieving the will to correct such problems is very unlikely".

    Do you consider those words constructive efforts to engender dialog?

    I've pretty much ceased to try and engender dialog, because: a) past experiences show tell me I'd be wasting my time; and b) because I believe it is too late to do so.

    I've considered attempting to start afresh on a stack-based VM that targets kernels threads from the ground up. Kernels threads because a) they're the ONLY form of concurrency that scales on modern, multi-core cpus; b) because all the other forms of single process concurrency can (easily) be layered on top. No other form of threading can make that claim.

    But I realise that I don't have the skills to do it alone; nor the following to get the right skills behind it.

    So yes. It is my opinion that Rakudo is too little to late. And I reserve the right to express that opinion. Do you deny me that?


    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.