use Perl

• Finding the bottleneck... (Score:2)

  by pmichaud (6013)

  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. Wha
  • Re:Finding the bottleneck... an update (Score:2)

    by pmichaud (6013) on 2009.06.01 11:50 (#68891) Homepage Journal

    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 number of iterations down to 10,000):

    use v6;
    my Int $i = 0;
    my @numbers;
    until ( $i == 10000 ) {
      @numbers[$i] = $i;
      $i++;
    }

    Using the May 26 version of rakudo, this program required 24.1 seconds to complete on my system. With the fixes I checked in this morning, it now requires 6.4 seconds -- a 75% improvement. Yes, this is still incredibly slow as compared to Perl 5, but this was just one optimization, and we have a *lot* more to go. Indeed, I found several more pathological Rakudo/Parrot issues while investigating this one.

    While on the topic, I'll note that placing the "Int" type constraint on $i currently makes things run slower, not faster, because it imposes an extra check on each update of $i's value. Without the constraint (i.e., "my $i" instead of "my Int $i") the program runs 0.4 seconds faster. Eventually we plan to do some type-based optimizations that will detect cases like this and optimize further, but in the general case that's a challenging problem and so we're focusing on other items. So, for the time being, keep in mind that type constraints on variables in Rakudo currently tend to make things run slower.

    Thanks again for this very useful post!

    Pm

    Reply to This

    Parent

    • Re: (Score:1)

      by korpenkraxar (9237)

      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.