Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • For the most part, Rakudo development has been focused more on speed than features. We're also somewhat hampered by the fact that Parrot doesn't have many good profiling tools so that we can figure out where the bottlenecks are. Those are supposed to be in place for the next major release in July.

    This post generated a lot of very fruitful discussion on #parrot today. Many people speculated about why the loop might be as slow as it is, and offered suggestions about improving Rakudo's code generation. What we determined is that Rakudo's code generation is in fact pretty good, there's not a lot of optimization to be had there. I already suspected this to be the case, and so when things like this have occurred I've guessed that Parrot is a big source of the slowdown.

    But, a few more forensic tests showed that wasn't the case either -- while Parrot doesn't perform nearly as well as we'd like or expect it to, it wasn't the primary source of the slowdown in this code either.

    It turns out that the slowness comes almost entirely from Rakudo's implementation of postfix:<++> -- its a very sub-optimal implementation that was written without the benefit of more recent Perl 6 specifications. Replacing the (generated) call to postfix:<++> with a simple integer increment (and changing nothing else) resulted in an 80% improvement on my system. So, there's a bug in the design or implementation of postfix:<++> somewhere (and a couple of optimizations), and I'll be looking at that today/tomorrow.

    More importantly, this points out why we really benefit when people write about their Rakudo experiences, good or bad. It helps us to see where we need improvements, to build a stronger case for throwing more resources at the bigger problems we need solved (e.g., parrot profiling tools), and to track down little surprises like this one. I can tell you that nobody involved suspected that postfix:<++> was the culprit here.

    Thanks again, and I'll report back with updated timings once we have postfix:<++> fixed.

    Pm

    • For the most part, Rakudo development has been focused more on speed than features.

      Oops, I obviously meant to write "...focused more on features than speed."

      Pm

    • Wow! I am very happy to see my post not only being read by the right people and not immediately discarded as "Perl6 bashing", but actually resulting in an immediate identification of parts of the problem.

      I actually hesitated to publish this at all, thinking that the problem was on solely on my part. I'm glad I knew better :-)
    • As mentioned previously, I'm reporting back with our status. In the course of investigating this program, we discovered that postfix:<> was in fact very badly implemented, making it far more expensive than it needed to be. Fixing this ended up requiring quite a few internal changes to Rakudo, and I've discovered even more things we want to fix/avoid when running Rakudo in Parrot.

      That said, here's where things stand now. I used the following code as a bench mark (basically same as original, cut the

      • It seems you are indeed right about the postfix being an important bottleneck. It never even occurred to me to change that to some other way of incrementing $i, but this is how it looks for me doing 10000 iterations:

        $i++; # 7.5s

        $i += 1; # 3.5s

        $i = $i + 1; # 3.5s

        In all cases it uses the expected ~130MB RAM, so at least there does not seem to be a significant leak specific to one of these expressions.