News for hackers. Stuff that matters.

A comment on Optimizing Ruby lazy initialization in TruffleRuby with deoptimization. Parent comment

Re:Optimizing Ruby lazy initialization in TruffleRuby with d... by tom_mellior on Saturday April 11, 2020 @05:11PM (#22844284)
In addition, it's interesting to see that TruffleRuby does better than CRuby on the longer running benchmarks, and worse on the shorter ones. The page claims that JIT warmup "is applied when necessary", but there are no further details. If I had to bet, I would guess that in the case of TruffleRuby maybe not enough warmup is being done in these experiments.
[ Parent | on HN ]
Re:Optimizing Ruby lazy initialization in TruffleRuby with d... by eregon on Monday April 13, 2020 @11:55AM (#22856919)
Seems there isn't any warmup accounted for: https://github.com/kostya/benchmarks/issues/246
[ Parent | on HN ]
Re:Optimizing Ruby lazy initialization in TruffleRuby with d... by kipply on Saturday April 11, 2020 @05:22PM (#22844366)
That sounds likely, but if it's not warmed up in some amount of time that a decent programmer believes to be enough, that probably means that it's warming up too slowly! With that being said, it could also mean that the faster ones could be even faster.

I totally expect base64 to perform like this though. It spends like one line in Ruby and then it's shipped off into the C extension, so really it's testing the differences between Sulong (LLVM bitcode interpreter for Graal) and a proper C compiler.

[ Parent | on HN ]