http://qs1969.pair.com?node_id=1099617


in reply to Rakudo Perl 6 and MoarVM Performance Advances

On OSX 10.8 with Perl 5.16 and Perl6/MoarVM 2014.08 I ran these one-liners against a 17Mb Apache log file:

perl -wnl -E 'say $1 if /\b(\w{5})\b/' logs.txt

perl6 -n -e 'say $0 if ~~ m/(<<\w**5>>)/' logs.txt

Perl 5 took 1.2 seconds and Perl6 2mins. 49 seconds so I'm not confident that Perl6 will ever be anywhere near Perl 5 for common use cases such as this.

Replies are listed 'Best First'.
Re^2: Rakudo Perl 6 and MoarVM Performance Advances
by salva (Canon) on Sep 05, 2014 at 10:02 UTC
    I'm not confident that Perl6 will ever be anywhere near Perl 5 for common use cases such as this.

    In Perl 5 regular expressions are handled by an ad-hoc, highly-optimized matcher (it's like a different interpreter). In Perl 6 (well, Rakudo, actually) I believe they are just compiled into regular "bytecode" which is then executed by the virtual machine as any other perl 6 code.

    Perl 6 approach is much more generic and powerful but it would take a while until all the involved layers get as fast as the ad-hoc perl5 matcher. In the worst case, Rakudo could just fall-back to the perl 5 approach for simple regular expressions.

[reply]
Re^2: Rakudo Perl 6 and MoarVM Performance Advances
by FROGGS (Novice) on Sep 05, 2014 at 10:43 UTC

    .lines() and -n are really really slow in rakudo, the code behind that is not really clever, compared to the code in Perl 5 (there is a talk by leont about what P5 does there).

    This should be better:

    perl6 -e 'grammar G { token TOP { <line>* }; token line { \N*\n } }; class A { method line($m) { say ~$0 if $m ~~ m/(<<\w**5>>)/ } }; G.parse(slurp(), :actions(A))'

    If tested that on a file from my box, result:

    Perl 5: 0.2s

    Perl 6: 6.2s

    That would mean that it might take about 45s on your box... can you verify that?

    Note 1) String handling is the slowest part in rakudo atm.

    Note 2) You should not compare printing the .gist of a match to a string from another language. Because Date::Dumper-ing an object in P5 is not really fast either. And that is what .gist somewhat is. (.gist is the human friendly nice formatted version of Data::Dumper aka method .perl)

    Note 3) I promised to look into the cheats P5 does when walking over lines, and I'll do that this weekend.

[reply]
[d/l]

      Results for a similar 19MB log file on my 2013 Macbook Pro:

      Perl 5: 0.68 secs
      Perl 6/Grammar: 49.8 secs

      … so 73 times slower.

[reply]
        Aiui your 73X slower result came purely from changing your code, not an improved compiler. Right?

        A variety of related changes to the compiler (and its toolchain) have since landed in the Rakudo, NQP and MoarVM HEADs. Aiui these will deliver significantly better results for both your original and grammar versions.

        The really big upcoming performance breakthrough for P6 will be the "Great List Refactor". The GLR, which has been discussed for years, is expected to have a very big impact on the execution speed of lists, arrays, etc. in typical code, substantially reducing RAM usage too in many scenarios.

        PerlJam recently said he's "working on a TPF grant to pay for having jnthn, TimToady, and pmichaud kidnapped and locked in a room" to do the GLR. Joke or not, it reflects the practical bus number on this (three, imo) and the ideal scenario (all three focusing on the GLR for a few weeks).

        Larry Wall, who has been getting his hands increasingly dirty for a year or so now (hacking on Rakudo and its toolchain), has been preparing for the GLR by reading guts code, profiling, and landing various related changes over the last few months. Larry's recent discussion of some things the GLR will take in to account may be of interest.

        Fwiw, when PerlJam recently wondered aloud "if it's worth adding GLR to S99", Larry responded "I hope to make the term obsolete pretty soon". Here's hoping we'll see a big GLR performance jump this year.

        One can reasonably expect significant further performance improvements every month for years to come. This year has seen Rakudo, NQP and MoarVM gain classic optimization phases, frameworks and tools. Some work taking advantage of these has already happened, so there have already been big improvements many months this year, but a lot of improvement is still ahead of us. For example the MoarVM JIT is in good shape in the sense it works and already slightly speeds up some code, but most of the benefits are yet to come.

        »ö« . o O ( "the celebrity tell-all of the Perl-6 cult?" )

[reply]
Re^2: Rakudo Perl 6 and MoarVM Performance Advances
by Mouq (Initiate) on Sep 05, 2014 at 06:39 UTC

    FWIW, perl6 -ne 'say ~$0 if m/(<<\w**5>>)/' … is much faster. Something likely needs to be optimized in Match.gist. It's still much slower than Perl 5

[reply]
[d/l]
[select]

      Additionally, appending  for lines gives a significant gain over using -n, so that needs works as well.

      EDIT: I agree that '-n' should be what is used here, I was moreso posting in the interest of figuring out why that's so slow. I just made a PR which seems to bring the time for '-n' to be more like that of 'for lines'

[reply]
[d/l]
[select]

        It could be argued you're then comparing different things. The original is strictly a comparison of the equivlaent Perl one-liners.

[reply]
Re^2: Rakudo Perl 6 and MoarVM Performance Advances
by grondilu (Friar) on Sep 05, 2014 at 06:14 UTC

    That's not great indeed. I don't really hope this will make much of a difference, but you did not have to capture the match with parenthesis. You could have just used $/:

    perl6 -n -e 'say $/ if m/<<\w**5>>/' logs.txt

    On the other hand, even if this does make a difference, the optimizer should have converted it automatically.

[reply]
[d/l]

      Perl 6 now 2 mins. 20 seconds. For the record Ruby 2.1:

      ruby -wnl -e 'puts $1 if /\b(\w{5})\b/' logs.txt

      ... completed in 2 seconds.

[reply]
[d/l]

In Section Perl News