4 ms·

Wait, the benchmark to find the 35th fibonacci number took 1.077s for the Zig VM vs 1.657s for the Rust VM? I realise that these VMs are going to be totally id

Wait, the benchmark to find the 35th fibonacci number took 1.077s for the Zig VM vs 1.657s for the Rust VM? I realise that these VMs are going to be totally idiomatic Zig/Rust, with the most straightforward implementation possible, and little-to-no performance tuning, but even so - that's gotta be a typo, right? Or it's actually finding `fib(350)`? Or each "run" is actually finding `fib(35)` 100 (1000?) times?

fizx 4y ago
It's intentionally using the naive 2^N solution to stress test lots of tiny function calls.
- dhruvdh 4y ago
  There is no way it will take a whole second regardless. Even when compiled in debug mode, it takes about 100 ms. Try it here, I had Bing AI write it out - https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=fb977f063a167c6d347e10d302b5fad2 https://play.rust-lang.org/?version=stable&mode=release&edit...
  - estebank 4y ago
    OP isn't talking about the performance of Rust code to calculate fib(35), but rather the performance of a Rust implementation vs a Zig implementation of an interpreted language executing code to calculate fib(35). They are saying that the Rust VM they wrote is slower than the Zig VM they wrote.
    - munificent 4y ago
      And, in particular, an interpreted dynamically typed language.
      - jeffdn 4y ago
        From a book that was a real joy to read and take one’s first steps into the magical world of compilers —- thank you for writing it!
        munificent 4y ago
        You're welcome! I'm glad you liked it.
  - deleted 4y ago
    [deleted]
TheRealPomax 4y ago
No caching, every recursive call runs the entire chain from scratch. fib(35) without caching takes roughly 14 million calls to resolve.
- deleted 4y ago
  [deleted]
maxbond 4y ago
I think the VM is operative here. My native Rust implementation found fib(35) in 51ms, but my Python implementation took about 1500ms (similar to their measurements). (I eyeballed the assembly to make sure the native implementation was recursive, but that's the extent of my rigor - consider these napkin numbers.)
- Karellen 4y ago
  Yeah, it was using the naive recursive implementation instead of a tail-call recursive variant that I wasn't expecting. I should have been expecting it. You're testing the performance of the runtime, not the program, so of course you want a bad implementation of the algorithm to stress the runtime as much as possible. (My tail-call Python implementation tops out at fib(997) in 720ms. Calling fib(998) gives me a "RecursionError: maximum recursion depth exceeded". AIUI python is never going to optimise away tail calls, but because the tail-call variant is O(n) anyway it still works out orders of magnitude faster.)

fizx 4y ago

It's intentionally using the naive 2^N solution to stress test lots of tiny function calls.

dhruvdh 4y ago
There is no way it will take a whole second regardless. Even when compiled in debug mode, it takes about 100 ms. Try it here, I had Bing AI write it out - https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=fb977f063a167c6d347e10d302b5fad2 https://play.rust-lang.org/?version=stable&mode=release&edit...
- estebank 4y ago
  OP isn't talking about the performance of Rust code to calculate fib(35), but rather the performance of a Rust implementation vs a Zig implementation of an interpreted language executing code to calculate fib(35). They are saying that the Rust VM they wrote is slower than the Zig VM they wrote.
  - munificent 4y ago
    And, in particular, an interpreted dynamically typed language.
    - jeffdn 4y ago
      From a book that was a real joy to read and take one’s first steps into the magical world of compilers —- thank you for writing it!
      - munificent 4y ago
        You're welcome! I'm glad you liked it.
- deleted 4y ago
  [deleted]

TheRealPomax 4y ago

No caching, every recursive call runs the entire chain from scratch. fib(35) without caching takes roughly 14 million calls to resolve.

deleted 4y ago
[deleted]

maxbond 4y ago

I think the VM is operative here. My native Rust implementation found fib(35) in 51ms, but my Python implementation took about 1500ms (similar to their measurements). (I eyeballed the assembly to make sure the native implementation was recursive, but that's the extent of my rigor - consider these napkin numbers.)

Karellen 4y ago
Yeah, it was using the naive recursive implementation instead of a tail-call recursive variant that I wasn't expecting. I should have been expecting it. You're testing the performance of the runtime, not the program, so of course you want a bad implementation of the algorithm to stress the runtime as much as possible. (My tail-call Python implementation tops out at fib(997) in 720ms. Calling fib(998) gives me a "RecursionError: maximum recursion depth exceeded". AIUI python is never going to optimise away tail calls, but because the tail-call variant is O(n) anyway it still works out orders of magnitude faster.)