Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

A $dayjob Perl 6 program that runs 40x faster on the JVM than on Parrot

by raiph (Chaplain)
on Aug 03, 2013 at 07:48 UTC ( #1047676=perlmeditation: print w/replies, xml ) Need Help??

All the usual Perl 6 caveats apply1.

Solomon Foster is a P6 developer. He has written some tools in P6 that he has been using to do work for his $dayjob since late last year. About a week ago he "had a specific goal I needed to accomplish for my day job". I'll let him tell his Rakudo performance story and/or you can follow the #perl6 log (starting at his first proper description of some problems he was having).

1 Perl 6 is not remotely as usable and useful as Perl 5; it has just a few dozen users; it is 100-1000x 10-100x slower than Perl 5 for a lot of stuff; the P6 documentation is immature and incomplete; the spec test suite has not reached 6.0.0; the Rakudo compiler has not fully implemented what's already in the spec (test suite) {ed: 6.c}; most of the concurrency implementation has only just begun is immature; P6 can not currently use CPAN modules; Perl 6 has syntax and semantics that are not backwards compatible with Perl 5; Perl 6 culture is -Ofun which some think is incompatible with getting things done; some folk think that Perl 6 code looks like line noise... In summary, there are infinitely many things wrong with P6.

  • Comment on A $dayjob Perl 6 program that runs 40x faster on the JVM than on Parrot

Replies are listed 'Best First'.
Re: A $dayjob Perl 6 program that runs 40x faster on the JVM than on Parrot
by 5mi11er (Deacon) on Aug 05, 2013 at 23:19 UTC
    Around 3 lifetimes ago, I was somewhat excited about perl 6.

    Since then, my interest has gradually waned to the point where I no longer care.

    I totally agree with sundialsvc4 above. Even if perl 6 is EVER released, which I believe the chances of that happening are less than 50% now, I strongly suspect that almost no one will care.

    Academically, I'm sure there are important lessons being learned and ideas being developed, hopefully many of those lessons are how not to develop a new language. But, in terms of a comercial success? I believe it just ain't gonna happen.


Re: A $dayjob Perl 6 program that runs 40x faster on the JVM than on Parrot
by grondilu (Friar) on Aug 06, 2013 at 05:50 UTC

    To me, any improvement in rakudo's speed is good news. I think if rakudo could be about as fast as Perl 5, more Perl 5 people would start using it, even if it's not complete yet. Then we'd have more people helping the development of rakudo, and eventually we'd have a full implementation.

    There was a Perl 6 conference lately, called The need for speed, and I think the speaker totally nailed it with his title. Perl 6 is quite well implemented now (still much to do but the most part is here), but now it really needs speed.

      Definitely naive.   Honest, I do not “anything personal” when I say that ... (a) this project was and always has been “an abstract exercise in programming-language design,” and (b) that it missed-the-boat almost from the beginning by being unable to standardize (and, importantly, to own) its runtime foundation.   (It frankly looks to me like there were “lots of committees and no decisions;” that it’s been that way for a decade; that it’s still that way.)

      Let’s say, not-too hypothetically, that I own a company whose star client budgets $4+ million a year to keep in 24/7/365 operation a system that runs their warehouse, as well as another system which once-an-hour rebalances the inventory demand projections which determine which product mix is shipped to what store through all of its warehouses.   All of which runs right-now on Perl-5, so “That is The Bar.”   And yet, here you are seemingly ecstatic that this Parrot thing runs 40(!) times slower than the well-known pig that runs Java?!

      I’ve made the comment before:   a worthy-successor to Perl-5 must be driven by actual developer-demand (not an abstract notion of what would be Kewel ...), must be fully and provably backward compatible with the now-vast installed base, and in every way must assuage the overwhelming deal-breaker consideration of business risk.

      If you “take it personally,” you’re taking my comment the wrong way.   This is pure business.   Billions of dollars of it.

      ... I think if rakudo could be about as fast as Perl 5, more Perl 5 people would start using it, even if it's not complete yet. ...

      Sounds naive. Maybe 5,8,10 years ago there might have been some potential of this happening (not very much potential), but there is zero chance (minus potential) of this happening today. Once burned, twice shy.

Re: A $dayjob Perl 6 program that runs 40x faster on the JVM than on Parrot
by sundialsvc4 (Abbot) on Aug 05, 2013 at 13:04 UTC

    This has turned into Willy Lohman crossed with &ldquo:I coulda been a contendah.”   Or, seeing George Forman selling pots and pans.   The race was run years ago, and you never finished.   Since then, the race-track has been torn up and they’ve put up a parking lot.   Even so, the carcass flops around on the pavement, boasting of 40x speed differences between one execution-language and another ... a metric which unfortunately points very clearly to the presence of irreconcilable design flaws if anyone had reason to care about them any more, which they do not.

    It doesn’t take any special credentials at all to set out to create a programming language:   people do it in high school these days, and they have one semester in which to do it.   But that is not where “the bar” is here.   “The bar” is, for example, a web-site with 3 million users and a development budget of $200,000 (USD) per month.   Or, a key transaction-processing system for a retail supplier that handles 50,000 transactions a minute 24/7.   Perl-5 does that now.   The technical requirements for anything that presumes to call itself Perl-5++ are hard, and high.   This project did not win.

Re: A $dayjob Perl 6 program that runs 40x faster on the JVM than on Parrot
by Anonymous Monk on Aug 03, 2013 at 09:21 UTC
    I don't know what's more impressive, that Perl-6 finally has a real user, or that this benchmark story is even less interesting than Alioth.
      Solomon isn't the first "real user".

      Would you be interested in the results of microbenchmarks or minibenchmarks rather than macro/$dayjob benchmarks like Solomon's?

      Solomon's story might not be interesting to you, but it stands in sharp contrast to this recent speculation:

      Prediction: Rakudo JVM will perform modestly better than Rakudo Parrot, mostly because rewriting NQP yet again can only improve it. It won't be the magical candy-vomiting unicorn panacaea that the Perl 6 marketing department wants to believe. It'll also take longer to reach stability than the marketing department wants to believe, and it'll use a lot more memory. A few microbenchmarks like tight loops of numeric code will look really good, but any program that exercises the parser (for example) will perform atrociously.

      As it turns out, just 2 months later, Rakudo/JVM is already 40x faster than Rakudo/Parrot for Solomon's use case, it's already passing about the same number of spectests as Rakudo/Parrot, which puts it about 2 months ahead of the schedule suggested publicly in May, and it's clearly not performing atrociously at parsing (because that was Solomon's use case). I only recall one bit of news about memory, which was a minibenchmark, and it showed Rakudo/JVM using twice as much.

      So, score one for the above commenter. (For now; I expect to revisit the issue of memory consumption on Rakudo VMs later this year.)

      In 2009 I predicted Perl 6 would get to 6.0.0 and a generally robust state about a year from now. While I think that estimate has turned out to be a little optimistic (by a year? two? -- I did not anticipate how things would pan out with Parrot, nor the negativity toward Perl 6 being voiced by some leaders in the Perl community which I suspect has had an effect) I urge any monks who were ever interested in contributing to Perl 6 to come check it out again on the IRC channel #perl6 on freenode. Hope to see you there. :)

        In 2009 I predicted Perl 6 would get to 6.0.0 and a generally robust state about a year from now.

        In the very link you posted, you predicted that Rakudo would be "ready in 2010 for use in limited ways" and in "another year or two (from 2009) to be usable for limited production contexts". If I were you, I wouldn't keep bringing up your powers of prognostication.

        ... nor the negativity toward Perl 6 being voiced by some leaders in the Perl community which I suspect has had an effect...

        Why do I keep having to tell you that this argument is nonsense?

        I've said plenty of unpleasant things about a lot of languages (PHP, Java, Python, Haskell, C, C++, Perl 5, SQL, Javascript) and yet people use those, so I very much think that the expression of my opinion really isn't the primary driver of language adoption (or disadoption) that you seem to think it is.

        People aren't avoiding Rakudo because I say it's a project floundering in the wilderness without the supervision of an adult who really wants to make it into a useful and usable product for general consumption. People are avoiding Rakudo because P6 hasn't delivered anything useful and usable for general consumption in thirteen years. How many times (for one example) does someone like Sebastian Riedel have to say "Gee, I wish Rakudo supported sockets!" before you figure out that the lack of any sane socket support is keeping him from doing anything he wants to do with it? How many times (for another example) does someone like me have to say "Gee, I wish Rakudo had documentation that wasn't a pile of specification tests hyperlinked to synopses under constant churn!" before you figure out that maybe documentation would be a nice thing? How many times does someone have to get on #perl6 and say "I tried to use this module, but it didn't work!" before you figure out that maybe keeping a working ecosystem might let people get things done?

        As for Solomon's benchmark, it doesn't rise to the level of data because it's merely an anecdote without context. Until and unless someone can explain why one implementation is faster than the other, it's just gossip.

        OK, so a very partial implementation of Perl6, on a virtual machine that was designed for an absolutely different language, is 40 times faster than on a virtual machine that was designed specifically for this kind of languages. After some fifteen years of development. And it's an achievement.

        Enoch was right!
        Enjoy the last years of Rome.

        What are the list of things that prevent Rakudo-on-whatever being labelled as a full fledged production release?

        Speaking as a user, I don't care what Rakudo runs on. I will take a Rakudo-on-anything. That is spec complete, with good documentation, and a good set of standard libraries(As it is with any new language).

        Whether that is JVM or your-own-VM, Who really cares? What one needs currently is one spec complete, well documented, stable, with libraries release. Not 10 half done releases.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1047676]
Approved by moritz
jedikaiti's brain hurts

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2017-09-22 21:59 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (269 votes). Check out past polls.