Ruby Outperforms C: Breaking the Catch-22(railsatscale.com)
railsatscale.com
Ruby Outperforms C: Breaking the Catch-22
https://railsatscale.com/2023-08-29-ruby-outperforms-c/
5 comments
In the Lua world, there's a project, Pallene[1], that aims to solve this problem in paricular[2].
[1]: https://github.com/pallene-lang/pallene
[2]: http://www.inf.puc-rio.br/~roberto/docs/pallene-sblp.pdf
[1]: https://github.com/pallene-lang/pallene
[2]: http://www.inf.puc-rio.br/~roberto/docs/pallene-sblp.pdf
Nice to see people are considering other languages than python.
Seriously??
Outperforming optimised C is basically impossible for any JIT.
Theoretically, a JIT can do better because it can know more specifics but in practice it just doesn't happen.
Outperforming optimised C is basically impossible for any JIT.
Theoretically, a JIT can do better because it can know more specifics but in practice it just doesn't happen.
I too can write python code the achieves the same end goal and is quicker than C code.
Doesn't mean it did the same amount if work or even uses the same algorithms and data structures but it did achieve the same end goal.
Unfortunately comparing two "languages" in the way it was done in this paper only seems to prove that for the subset of edgecases the author needed to handle his Ruby implementation could make tradeoffs that are quicker than the off the shelf C extention.
Had he then went on to actually rewrite the code that was a bottleneck in C making the same tradeoffs it might have been
Doesn't mean it did the same amount if work or even uses the same algorithms and data structures but it did achieve the same end goal.
Unfortunately comparing two "languages" in the way it was done in this paper only seems to prove that for the subset of edgecases the author needed to handle his Ruby implementation could make tradeoffs that are quicker than the off the shelf C extention.
Had he then went on to actually rewrite the code that was a bottleneck in C making the same tradeoffs it might have been
From the article:
> In other words, we have a tight loop that makes many Ruby to C to Ruby calls. YJIT (as well as other JIT compilers) have a hard time optimizing these types of calls.
Basically the benchmark compares two Ruby gems, one which can be optimized and another which cannot.
And to much surprise, the gem that cannot be optimized performs worse.