Re:Ruby Outperforms C: Breaking the Catch-22
by jpc0 on Wednesday August 30, 2023 @09:20AM
(#37321712)
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
Re:Ruby Outperforms C: Breaking the Catch-22
by rewmie on Wednesday August 30, 2023 @09:23AM
(#37321770)
The title is pure clickbait, and completely misrepresents the actual problem and benchmark.
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.
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.
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.
[1]: https://github.com/pallene-lang/pallene
[2]: http://www.inf.puc-rio.br/~roberto/docs/pallene-sblp.pdf