[raiph]

> I would [guess?] that [Raku(do)] is using hyper operators and internal concurrency to "cheat".

You missed a word. I've guessed it was the word "guess". :)

I haven't checked Rakudo's code but I'm pretty sure any performance optimizations of your code were not related to using hyperoperators or internal concurrency.

Here's two things I can think of that may be relevant:

* Rakudo tries to inline (calls to) small routines such as `* + *`. Wikipedia's page on inlining claims that, when a compiler for a low level language (like Rust) succeeds in inlining code written in that language it tends to speed the code up something like ten percent or a few tens of percent. In a high level language (like Raku) it can result in something like a doubling or, in extreme cases, a ten fold speed up. The difference is precisely because low level languages tend to compile to fast code anyway. So while this may explain why Raku(do) is faster than CPython, it can't explain your conclusion that Rust is half as fast as Raku. (I think you almost certainly made a mistake, but let's move on!)

* In your Raku code you've used `...`. That means all but the highest number on the command line are computed for free, because sequences in Raku default to lazy processing, and lazy processing defaults to use of caching of already generated sequence values. So a single run passed `10 20 30 40` on the command line would call the `* + *` lambda just 40 times instead of 100 (10+20+30+40) times. That's roughly a doubling of speed right there.

So if Rakudo is doing a really good job of codegen for the fibonacci code, and you removed the startup overhead from your Raku timings, then perhaps, maybe, Raku(do) really is "beating" Rust because of the `...` caching effect.

I still find that very hard to believe but it would certainly be worth trying to have someone reasonably expert at benchmarking trying to repeat and confirm your (remarkable!) result.

> At this point in its evolution, there is still much work to be done on code optimisation.

Understatement!

It took over a decade for production JVMs and JS engines to stop being called slow, another decade to start being called fast (but not as fast as C), and another decade to be considered surprisingly fast.

Rakudo's first production release came less than a decade ago. So I think that, for now, a reasonable near term performance goal (I'd say "by the end of this decade") is to arrive at the point where people stop calling Raku slow (except in comparison to C).

> Let me try a translation:

Let me have a go too. :) But I'll rewrite the code:

    sub MAIN                         #= Print fibonacci values.
        (*@argv);                    #= eg 10 20 prints 55 6765

    print .[ @argv ]                 # print fibonacci values.
      given
        0, 1, 1, 2, 3, 5,            # First fibonacci 
    values.
        sub fib ( $m, $n )           # Fibonacci generator
                { $m + $n } ... Inf  # to compute the rest.**

[librasteve]

yes guess (thanks!)

well - try it on your own machine - code as noted above (with reflection of the input value)

then,

  > time raku fibo.raku 10 20 30 40
  
  10 55
  20 6765
  30 832040
  40 102334155
  raku fibo.raku 10 20 30 40  0.11s user 0.01s system 116% cpu 0.133 total

Caveat - this is absolutely not purporting to be a benchmark, it was as big a (pleasant and counterintuitive) surprise to me as to anyone.