On Thu, Jun 04, 2009 at 12:12:06AM +0200, Chris Mair wrote: > I'm new here, so forgive me if this is not the right list.
You're in the right place! > After having used perl5 a lot years ago, this weekend I > finally decieded to have a look at perl6. > [...] > Anyway, the parrot and rakudo files were downloaded and > built in around May 31 22:00, however. > > Now, my problem is that perl6 code runs very slooooooow :( > [...] > So, my question: is there something fundamentally > flawed in how I'm using rakudo (i.e. I'm doing something > silly), or is this just the state of things at the time > being? You're correct, it's very slow. Incredibly slow. Slow as in "There's no way it could possibly be that slow" sort of slow. That's just the state of things now... but read on. First, a discussion similar to the example you just gave came up on use.perl just this past weekend [1,2], and it turns out that our implementation of "++" was pathologically slow. So, I fixed that on Monday (June 1st), and things are now significantly faster. (Read the use.perl post for more details): [1] http://use.perl.org/~korpenkraxar/journal/39051 [2] http://use.perl.org/comments.pl?sid=43083&cid=68873 More importantly, it turned out that though many of us felt we knew where the problem was likely to be, we didn't find the postfix:<++> issue until I actually did some measurements on it. That tells us that (1) we need more examples to measure, and (2) we really need some better measurement tools for Parrot. We're well aware of the need for #2, and we have some things in the works to bring resources to bear on that problem. Now then, just because things are fast*er* as a result of this fix doesn't mean they're fast yet. We're still a couple of orders of magnitude slower than Perl 5; we know it, we don't like it. But our focus thus far has been more on features than speed, because the only good way to optimize is to test real code, and we can't get a lot of real code until we have good feature coverage. But we do have lots of ideas about where optimizations can still occur, and we get to them as they become "ripe" for implementation (or when we discover pathological problems like postfix:<++> above). To give an idea of the speed at which we're adding optimizations... in mid-May it took Rakudo 51 minutes to run the spectest suite on my system. As of this morning it was requiring just over 23 minutes, and we're running/passing more tests now than we were then. That's a better than 50% speed improvement over the span of just 2.5 weeks. That's also without addressing many of the "deep" performance issue in Parrot; for example, we know that Parrot's calling conventions are far slower than they need to be -- those are currently undergoing a significant refactor, and we expect to see significant speedups when those land. So, it's the state of things today, but I don't expect it to be the state of things for long into the future. I don't know when (if ever) Rakudo will be able to outperform Perl 5 for simple programs like the one you gave, but I expect that even an order-of-magnitude difference in speed will be fast enough for many people to want to use Perl 6 instead of Perl 5. (And Perl 6 has more opportunities for optimization and customization than Perl 5 did.) Thanks for the question and post! Pm
