Categories

Posts in this category

Sat, 02 Jul 2011

How fast is Rakudo's "nom" branch?


Permanent link

Nearly one year ago, the Rakudo Perl 6 developers proudly released the first Rakudo Star, a distribution aimed at showing the world what Perl 6 can look like, and in turn get feedback from more early adaptors.

And feedback we got. While the overall response was very positive, people had one main concern: it was too slow. That didn't come as a surprise, considering that we had focused on features first. Now it was time to change that, and work on massive performance improvements.

That is easier said than done. One of the reasons is that Rakudo is tightly coupled to the parrot virtual machine, but there is a lot of mismatch between the two. For example parrot provides multi dispatch built-in, but not quite with the semantics that Perl 6 needs. Same for parameter binding, objects and a number of other areas.

In the following year, parrot got a new, faster garbage collector, and Jonathan Worthington came up with a cache for type checks at routine call time.

This sped up this simple mandelbrot fractal generator at size 201x201 from 18 minutes to 16 minutes 14 seconds. Actually the speedup was better than that, but we paid a performance penalty for new features, bug fixes and parrot performance regressions.

But it was clear that more substantial improvements where needed. One of the most promising candidates for speedups is a complete redesign of the object model, resulting in the "nom" (new object model) branch of Rakudo. Additionally to providing much more well suited OO primitives than parrot can offer right now, it also allows to share more information between compile time and run time, making a lot of optimizations possible.

Yesterday I sped up some operations on Complex numbers, and implemented a built-in that was missing to run the mandelbrot script. And today I timed it: 3 Minutes. From originally 18 Minutes.

Now that's a speedup by more than a factor of 5. I'm not sure if it will extend to other operators, but it sure is encouraging.

And that's without the optimizations that will now be possible, for example inlining operators. So after a literally slow start, Rakudo Perl 6 has a bright and fast future ahead. And it's already here, just not evenly distributed.

[/perl-6] Permanent link

Comments / Trackbacks:

Trackback URL: /blog-en/perl-6/how-fast-is-nom.trackback

ihrd wrote


Hi there! Parrot primitives do not match for Rakudo? It sounds odd a little. I have thought to host perl6 is parrot's major purpose.

BTW I'm happy to hear you made it faster!

Caleb Cushing ( xenoterracide ) wrote


If parrot doesn't do what you guys need... why aren't you improving parrot? why does it seem that rakudoers move away from parrot, instead of making parrot better? I'm sure that parrot needs improvements for other language implementations as well.

Patrick Michaud wrote

pmichaud
Q: "Why aren't you improving Parrot?"

A1: We *are* improving Parrot. The object system on which the nom branch is based ("6model") is expected to be backported to become Parrot's new object system. Similarly, nom and nqp have developed "native lexicals" (lexicals containing native int/num/str) and placed those into Parrot; and other improvements to PAST have found their way back into Parrot.

A2: The Parrot development culture has grown a fair distance away from what is needed for timely Rakudo development and progress, Parrot's organizational priorities are very different from Rakudo's in many ways. For example, due to Parrot's stability and backwards compatibility policy constraints, the 6model and other work that is absolutely vital to Rakudo's current development will likely not appear in a Parrot release until 2012 at the earliest. We feel that's far too slow a timeline for Rakudo development.

A3: We don't want Rakudo to be forever tied to Parrot, we want to be able to see Rakudo Perl 6 running in other environments such as the CLR and JVM. So many of our efforts are towards providing an efficient way to make use of multiple backends, instead of limiting ourselves to just Parrot.

Overall, what seems to be working out better (for Rakudo) at this time is for us to focus on building exactly what we need to run Rakudo well (independent of Parrot design/development), and then if it's appropriate we'll help to migrate those features into Parrot where other HLLs will be able to make use of them. But we don't want to be held back by the slower pace of development that Parrot requires.

Pm

chromatic wrote


A0: Funny, I remember offering to implement native lexicals in Parrot at least 18 months ago as well as an improved metamodel in Parrot last summer. I also remember quite the squawking every time Parrot doesn't hew to whatever interpretation of its deprecation policy Rakudo wants that day.

The phrase "the slower pace of development that Parrot requires" doesn't pass my smell test.

pmichaud wrote


Where Parrot's development pace is slower is in its deprecation policy, not in the addition of new features. I freely acknowledge that you were willing (even eager) to implement native lexicals in 2009; we weren't in a position to be able to use them then. The same is true for an object metamodel; you've been very willing to help implement a metamodel, but again, we couldn't define exactly what we need.

My experience in this area has been that we have some vague idea for a new feature or subsystem, a preliminary version makes it into Parrot releases and people start using it, and then when we discover we need some substantial changes it's difficult to make them inside of the Parrot ecosystem because it'll break existing usage of the subsystem. It's the refactors of existing subsystems that slow us down, not the introduction of new features.

Do you disagree that 6model is unlikely to appear in Parrot before a 2012 release? Will Parrot be willing to adopt a PCT and Regex engine with substantially different (and backwards incompatible) APIs before then?

I freely admit here that any current API deficiencies in PCT and NQP are arguably my own fault, as I wasn't able to precisely forecast in 2008 and 2009 what Rakudo would need in 2011. My point is that it's easier for us to develop the new systems outside of Parrot, and then offer them for Parrot adoption when they've stabilized.

As far as Rakudo devs squawking (even inconsistently from one day to the next) about Parrot not following its deprecation policy, I'm definitely guilty as charged, and I know it. We're just trying to keep Rakudo development going forward and find ways to deal with the occasional roadbump, not to cause problems. In the past, it's often felt as though squawking loudly and pointing at the deprecation policy was the only way we could get the issues timely addressed so that Rakudo could continue to operate. However, in May of this year both projects have adopted a "relationship management" policy that should drastically reduce these situations.

Pm

Write a comment

The comments on this blog post have been disabled; the comment form below will not work.

 
Name:
URL: [http://www.example.com/] (optional)
Title: (optional)
Comments:
Save my Name and URL/Email for next time