|
Re^2: A $dayjob Perl 6 program that runs 40x faster on the JVM than on Parrot
by raiph (Deacon) on Aug 04, 2013 at 01:56 UTC
|
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. :)
| [reply] |
|
|
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.
| [reply] |
|
|
my opinion really isn't the primary driver of language adoption
My interest is trying to encourage contribution not adoption. (I've always thought adoption will largely take care of itself and will reflect how robust the product is.)
People are avoiding Rakudo because P6 hasn't delivered anything useful and usable for general consumption in thirteen years.
By mid 2003 people were avoiding Mozilla because it hadn't produced anything useful and usable for general consumption despite spending many millions of dollars and 6 years on it. Because I knew what was going on behind the scenes, I chose to continue to contribute and try to attract more contributors in the face of ill-informed ridicule and attacks. The same applies to Perl 6.
sane socket support?
sri's issue is non-blocking sockets which depends on using the underlying VM's support for concurrency. As labster said less than a week ago, the current short term plan is "get the JVM working ... start getting threads flushed out ... then buffers, and sockets". As things stand right now the JVM is sufficiently working, some initial concurrency primitives including threads have been implemented (more have arrived since that commit), jnthn made a series of improvements to the Buf type just before leaving for a week vacation, and today, his first day since returning, he's begun making socket commits.
documentation that wasn't a pile of specification tests hyperlinked to synopses under constant churn
See Perl 6 documentation.
keeping a working ecosystem might let people get things done
People manage to get things done.
Module breakage is generally relative to git head, not Rakudo Star (the quarterly batteries included distribution which is what users wanting stability should use).
#perl6 is typically very responsive to any regressions brought to their attention by a user.
Head is developing rapidly. So there's often a lot of breakage against head. This has reached an all time peak in the last few weeks.
| [reply] |
|
|
|
|
|
|
|
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.
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
|
|
What's with "very partial"? Rakudo/JVM already passes over 99.3% as many spectests as Rakudo/Parrot and looks likely to surpass it this month.
It's absolutely not true that Rakudo/JVM is 40x faster than Rakudo/Parrot in the general case. (That's just for a particular run of Solomon's program.) Indeed it's been roughly 50/50 slower/faster on the benchmarks I've seen. The plan at the moment is to get the JVM port to match Parrot feature-wise and then look at optimizing it. (And I think MoarVM will get more optimization attention than the JVM.)
If Rakudo/JVM does get to be 40x faster than Parrot in the general case, it would be about 2x or 3x slower than Perl 5. (And one would then be able to use features such as native types to outperform Perl 5 for some work.) Imo that would indeed be an achievement, regardless of whether it took 13 or 15 years to get there. Not an achievement to brag about outside the Perl community, of course, but clearly of interest here at the monastery.
Imo, if Parrot had been "designed specifically for", or even sufficiently for, Rakudo, then Rakudo would have reached 6.0.0 as Rakudo/Parrot, MoarVM would not exist, and the JVM port would either not exist or be a lot less tactically important.
(Edit: added italics and parens to clarify.)
| [reply] |
|
|
|
|
|
|
|
|
|
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.
| [reply] |
|
|
What are the list of things that prevent Rakudo-on-whatever being labelled as a full fledged production release?
There'll likely be as many very different answers to that as answerers.
For one definition of "full fledged production release" that I think is arguably reasonable, the main missing absolute essentials are completed documentation and user support. I think aiming at producing such a release in the next few months would be a big waste of everyone's time.
Maybe you mean "like P5". That might never happen; you only get a QA level like P5's if you get an adoption level like P5's.
Extrapolating on the plans and progress of the last 2 years, and assuming no bus accidents, I can see the P6 team aiming at having a solid 6.0.0 beta that adds p5interop, compact arrays, concurrency, async IO, unicode, macros, module versioning, better libs, better module installer, much better performance, complete documentation, and user support by YAPC::NA 2014.
(In case anyone misinterprets this as promising big things or somesuch, this is not a promise but rather a list of the main things I think will be added between now and shipping a "full fledged production release".)
Update: P6ers showed pretty much zero interest in focusing on a 6.0.0 until very recently, a year later than I thought they might take aim, and they haven't said what date they will aim at, if any. But P6ers are now talking seriously about 6.0.0. I still think my list of things that P6ers will want to do before 6.0.0 remains about right. p5interop, concurrency, async IO, and a better module installer have arrived. Module versioning, libs, macros, performance, and doc have all improved but remain very much works in progress. Finally, work has barely begun on compact arrays and NFG (the key to P6's full approach to Unicode) but I still expect them to be part of anything officially called 6.0.0.
| [reply] |