in reply to Re^12: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?

Also I don't know why we would want to downgrade to LLVM.

That wasn't the point of my post, but it was also exactly the point of my post, so I'm not sure why we're having a discussion on how Raku will someday eventually be faster than Perl, because that's irrelevant to my point that the semantic mismatch between a language and its implementation is really, really important to performance.

The main reason grammars are slow is because basically no one has touched the slow parts of it for the better part of a decade.

I remember profiling and optimizing grammars in an earlier version a little over a decade ago, so.

It has absolutely nothing to do with being able to replace what whitespace matches.

I don't believe this, because:

Really if Perl doesn't do something drastic, in five to ten years I would suspect that Raku would just plain be faster in every aspect.

I've heard this every year for the past 10 years, but I respect that you're not promising it in the next year, like Raiph always used to. I'll believe it when I see it.

  • Comment on Re^13: Modernizing the Postmodern Language?

Replies are listed 'Best First'.
Re^14: Modernizing the Postmodern Language?
by b2gills (Novice) on Jul 26, 2020 at 18:44 UTC

    You do realize that there exists a project which acts like a JIT for compiled code right?

    It exists because a JIT has more information available to than the compiler, it can do a better job at optimization.

    The way Raku does it is even better than that because the JIT can actually sort-of ask the compiler what it really wants. Or rather the compiler gives the JIT enough hints ahead of time.

    The reason I actually gave a timescale, instead of just saying “future”, is because of the RakuAST project which will end up cleaning a lot of semantic mismatches in the process. It should also make a lot of optimizations easier to perform.

    The plan I believe is for Rakudo to switch to it within a year. Which allows 4 to 9 years for optimizations. Again those optimizations should be easier than the ones that already made Raku faster in some cases.
    (By faster I mean faster than Perl and C/C++ for some cases.)

    MoarVM is also getting a new dispatcher that should also be easier to add optimizations to. I don't recall seeing a timescale on that though.
    (At least some of those optimizations will probably happen before it gets completely switched to.)

    So two of the slowest parts are getting replaced with much more optimizable designs.

    An optimization is just a way to push the implementation of a language as far as possible from the semantics of that language without it being noticed.
    So you were sort-of right, the semantic mismatch between a language and its implementation is really really important to performance, only you had the argument backwards.

    Of course you want as little semantic mismatches that doesn't allow for optimizations, because that is still code.

    Rakudo is made of layers where each layer only has a slight semantic mismatch from its next higher or lower neighbor.
    This allows for much larger shifts of semantics at the lowest layer without it being noticed at the top layer.

    With perl there is pretty much exactly one layer, and it is the top layer. Which means you can't really change it all that much without changing semantics and thus breaking existing code. So there is a vast sea of optimizations that are just not possible.

    Also I would really like to know how allowing you to change what is considered whitespace as a semantic mismatch. Because it really isn't.

    The semantic mismatch between what is in my head and Raku is less than the mismatch with Perl.

    That is the most important mismatch to reduce, because it is the only one that can't be optimized away.

      It should also make a lot of optimizations easier to perform.

      I had that discussion a lot with Raku's lead developers in 2009 and 2010.

      Which allows 4 to 9 years for optimizations.

      We'll see, but I heard that in 2009 and 2010 too.