Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: Parrot, threads & fears for the future.

by audreyt (Hermit)
on Oct 23, 2006 at 14:08 UTC ( [id://580042]=note: print w/replies, xml ) Need Help??

in reply to Parrot, threads & fears for the future.

What if, the current non-Parrot Perl 6 implementation -- i.e. the one that has arrays and hashes and subroutines and hyperops and junctions and can natively use CPAN modules -- already implements SMP parallelism for hyper/junctions, exactly as you described?

What if the runtime system for this parallelization already supports huge numbers of "async{}" operations, with its preemptive lightweight concurrency, that scales linearly with the number of CPUs?

What if, the said implementation has a comprehensive support for Software Transactional Memory, with lockless contention resolution, rollback via "defer", choice of fallback via "maybe", and will soon provide invariants via "ALWAYS{...}"?

What if the syntax of of such STM primitives as designed by TimToady++ is supported by the semantics outlined by lizm++, one of the most knowledgeable person of concurrent Perl?

What if the community behind the runtime system is actively working on GPU co-processors, native support for SSE2 for numerical operations (already implemented for x86_64), and Cell/Grid parallelism?

What if the Intel folks I've met last week, who are actively profiling and tuning their multicore CPUs to work with GHC's pure computation and concurrent computation notions, are delighted that Perl 6 can take advantage of those optimizations natively?

Does that not inspire you, if not with confidence, at least curiosity and excitement? :-)

  • Comment on Re: Parrot, threads & fears for the future.

Replies are listed 'Best First'.
Re^2: Parrot, threads & fears for the future.
by BrowserUk (Patriarch) on Oct 23, 2006 at 17:18 UTC

    Yes AudreyT, it does inspire me. With curiosity, and excitement--and confidence.

    I've been keeping loose tabs on your progress ever since your first post in the Perl6 fora received it's initially rather brusque reception.

    Thanks to Mr. Wall's ability to prevaricate, stall and change his mind--until he gets it right, and the support of his team. Your vision; your ability to follow through on your vision; and your ability to inspire others to go with you; combines to give me a great confidence that not only will Perl6 be real--it'll be bloody amazing.

    My doubts, and this thread, are solely aimed at Parrot.

    Is Parrot important given Pugs? Pugs is still somewhat slow, though the latest build seems to be a great deal faster than previous builds. Can Pugs ever hope to achieve acceptable production performance?

    As far as I am aware, the intention is still to have a Perl6 compiler, written in Perl6, that can compile itself, and will (primarily?) target Parrot. My doubts centre on whether, given what I knew of the Parrot development up to ten months ago, it could ever hope to match the abilities you've already achieved with Pugs?

    Of course, you've leveraged a great deal of high quality development that has taken (10+?) years of some of the brightest minds in academia to get to where it is now. That's a pretty big heft up over where the Parrot guys started from.

    But the significant thing is that the guys at Glasgow see beyond the world of Unix, even though that's where they live. See the complementary merits of forks and threads. See the benefits of concurrency, and know that to achieve it, you have to build it in from the ground up--not tack it on afterwards.

    As another responder in this thread has shown very clearly, not only are not everyone in the Perl community so enlightened. Many actively decry that threads have any merit whatsoever. And up to 10 months ago, very few if any in the Parrot community were any better.

    Yet another responder, now a part of the Parrot team has pointed out that my knowledge of Parrot is out of date--something I pointed out myself elsewhere here recently. Still, on the basis of what particle has said, it still seems (to me at least), that threading has not been tackled early enough in the project to really ensure that it can be fully integrated into the project. At best it might require substantial rewrites of existing code to achieve that integration. At worst, it'll end up being a 'tack on' solution.

    As always in our few brief interactions, let me take the opportunity to thank you for your amazing work and inspiration.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Thanks for your kind words. *blush*

      The concept of One True Official Perl 6 is, well, officially gone. Much like other standard-based languages, anything that passes the conformance test suite is Officially Perl 6.

      Pugs's interpreted core will always focus on semantics rather than speed. In that regard it may one day be comparable to Perl 5, but not fundamentally faster than it. However, much as GHC has two cores (interpreted GHCi and natively generated C--), so will Pugs provide an ahead-of-time compilation mode that supports runtime modification through dynamic linking.

      The AOT mode scheduled for the next release is based on a new Meta Object model that can generate fast, native embeddings in both of Pugs's runcores, namely GHC and Perl5. That will get Pugs a performance comparable to compiled Haskell code on the GHC runcore, and as fast in the Perl5 runcore as we can, probably with help from new opcodes hacked into Perl 5.12. Both will be likely faster than what Perl 5 currently is.

      Pugs does not aim to be a cross-language bytecode interpreter that supports both static and dynamic method dispatch. CLR3, Java6, Rhino and plenty of other less mature VMs (Parrot, StrongTalk, HLVM, IO, YARV, PyPy) already do them pretty well, and all we have to do is to write a backend to generate bytecode for those platforms, in order to use their libraries.

Re^2: Parrot, threads & fears for the future. (parrot)
by tye (Sage) on Oct 23, 2006 at 15:17 UTC

    This is great news. Howsever, I think BrowserUk's point is more that Parrot is doomed. I'm not sure why he chose to never say "Parrot" except in the title.

    So audreyt's reply rather reinforces at least that part of BrowserUk's thesis. Parrot appears doomed. Though it'd be interesting to hear responses from those who know what is going on with Parrot as to whether this particular design mistake is as characterized by BrowserUk.

    - tye        

Re^2: Parrot, threads & fears for the future.
by jdtoronto (Prior) on Oct 23, 2006 at 14:51 UTC
    Yea verily!

    Of course what this says is that specifying something by a committe is fraught with difficulty and rarely will the documentation match reality until we are at the end of the process. Whilst BrowserUK does make the valid point that the spec documents don't yet reflect much of the work in the developer community, it's nice to hear that those of us in the non *nix world don't have to worry about merlyns often somewhat myopic view of the world of computing. We might not like *doze, but we do have to deal with it.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://580042]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2024-05-19 07:23 GMT
Find Nodes?
    Voting Booth?

    No recent polls found