Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

[Perl6] just got seriously faster

by Tux (Abbot)
on Aug 05, 2017 at 10:55 UTC ( #1196795=perlnews: print w/replies, xml ) Need Help??

Oké, it is still not as fast as perl5 (in parsing CSV), but 10% speed gain is (very) good.

Cheers to all people that worked on the code to achieve this. Still way to go, but we're well on our way.

Check out the speed graphs and the comparison to other languages and rejoice.


Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re: [Perl6] just got seriously faster
by BrowserUk (Pope) on Aug 05, 2017 at 12:09 UTC

    Am I reading those graphs correctly?

    1. The fastest P5/CSV_XS takes 0.010 seconds for 50,000 records.
    2. The fastest P6 implementation uses Inline::P5 and CSV_XS to achieve 1.953 seconds to do the same thing. 195X or 19,500% slower.
    3. The fastest P6 that doesn't resort to I::P5 and XS takes 3.443 seconds. 344X or 34,430% slower.

    Hm. "Seriously faster" is a relative term!


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

      I think 10% speed gain is seriously faster. And I started with the fact that there indeed still is a long way to go.

      When I started in October 2014 with CSV parsing in perl6, my first working copy took a whopping 256 seconds. From there to 3.5 is quite a thing and makes me hope it will eventually go down to 0.35, which is comparable to pure-perl implementations of CSV parsers.

      The fastest perl5 parser has no options whatsoever. No options means less if statements and more efficient loops. The perl6 parser has all the options Text::CSV_XS supports, and thus includes all the code paths, if statements and other constructs to support those features. If perl6 will be able to optimize next and last to end a loop other that through an exception, I expect this process to see a speed-up by factors instead of by percentages.

      I understand your stance towards perl6 not being ready for serious production when looking at speed, but if you also look at what the language offers, you might conclude that once you master the basic constructs, development-time in perl6 weighs up to solving problems in other languages. Writing scripts for complex tasks that do not depend on speed, but require serious thought in other languages, just write themselves in perl6. To me at least, it brought new insights in how I could be able to solve problems.


      Enjoy, Have FUN! H.Merijn
        I think 10% speed gain is seriously faster.

        Sorry, but a 10% improvement, when by your own admission an order of magnitude is required, doesn't come close to "serious" IMO.

        If perl6 will be able to optimize next and last to end a loop other that through an exception,

        I think you've hit the nail on the head.

        if you also look at what the language offers, you might conclude that once you master the basic constructs, development-time in perl6 weighs up to solving problems in other languages.... scripts for complex tasks that ... but require serious thought in other languages, just write themselves in perl6.

        P6 has a seriously powerful and interesting syntax; but unless that syntax can be converted into runtime code that runs efficiently, without resorting to requiring complex XS code, called via the P5 runtime, it means that whatever develop-time gains might be available are swamped by the need to also learn and use XS to achieve performance.

        There are several features of the P6 language that are simply too complex to ever allow the language to be interpreted efficiently. Any one of: generics, OO-exception handling, MOP, incremental regex, hypotheticals, junctions, lazy evaluation, macros, user-define operators, active metadata, introspection; preclude conversion to an efficient bytecode format.

        Just as the possibilities of overloading and tying & magic, impose constant runtime performance penalties on every Perl5 opcode, each of those P6 features adds the requirement for a runtime decision point and branch or an indirection. Any two or three combined would make the tasks of compile time and runtime (JIT) optimisation very, very tough.

        With all of them, the task is simply impossible in an interpreted language. With that number of permutations of decision points and indirections, the time taken to select and generate the optimised code paths, will be greater than the time required to run the unoptimised code.

        The fact that even when just calling P5/XS code from P6 to do the bulk of the benchmarked task, imposes an 2 orders of magnitude performance penalty, and that is lorded as a breakthrough...

        The only way P6 will ever run efficiently is if it is compiled; and that would require a multi-pass, iteratively refining compiler of the complexity of GHC, and that will have been under constant development by a well-funded succession of seriously clever professors and a nearly unlimited supply of cheap and enthusiastic undergrads and grads for thirty years in two years time!

        It's taken the last 15 years (my time with perl) for P6 to get to the point where being only 200x slower is a newsworthy event; I simply don't have the lifespan nor enthusiasm to wait another 15. I've got too much doddering and pottering and bitching loudly about the youth of today to do before I kick it, to even consider it.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
        From there to 3.5 is quite a thing and makes me hope it will eventually go down to 0.35

        Because performance improvements are always linear with regard to time and effort?

      Even setting aside XS, the fastest P6 vs P5 is 3.009/0.121=24.9, which is still pathetic. But there must be something wrong with their methodology, because they have Rust taking 0.000 seconds to C's 0.002, which is absurd.

        For C and Rust and less for the next few, the testing set is too small to be significant. Process management and system load have way more effect of these than on the others. If I however make the test-set bigger, the slower processes would take too much time.

        I already tried to subtract startup-time, but as the startup-time is about the same as the runtime, and so low that noise has more impact than the actual run-time, it is more like an indication that these processes are significant faster than the rest.

        Also note that the goal of these graphs are to show relative speed between the perl methods available. I added the other languages later out of curiosity.


        Enjoy, Have FUN! H.Merijn

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlnews [id://1196795]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2017-10-21 03:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My fridge is mostly full of:

















    Results (269 votes). Check out past polls.

    Notices?