I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?
I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify.
(Rest in peace, Chris, and may your memory be a blessing to those who knew you)
Tl;Dr it runs rails for a while already, it even runs mastodon.
Here was the announcement:
Also Oracle.
In what way? Truffleruby passes over 97% of CRuby's specs and it runs on my command-line without any problems so far. It was easy to install too. I'm sure if I dig into those failing specs I'll find something but will it be important? I'd love to know.
> Regarding performance, TruffleRuby is by far the fastest Ruby implementation on the yjit-bench benchmark suite which includes railsbench, etc. To achieve this performance TruffleRuby needs a fair amount of warmup, as other advanced JIT compilers do. If you find any performance issue, please see this guide.
One benefit of YJIT + cruby is it doesn't have the same warmup costs. If you're deploying many times a day, this JIT warmup becomes a dominant factor.
Very little of Graal/Truffle is locked behind an oracle license. The community edition is FOSS and within 5-10% of the performance of the paid version (so still an order of magnitude above MRI with or without YJIT). The situation is very similar to HotSpot/OpenJDK.
Source: I work in a team that's nearby as the org chart flies.
[0]: https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj... says
Also our experience with truffleruby is death by a thousand subtle differences. It might be 97% compatible but chasing down that 3% undocumented behavior difference on every minor version update for every gem got exhausting fast. Everyone uses and tests against cruby.
HN has been host to quite a few of these spats over the years and I wouldn’t want to deal with it, there are pretty much only downsides to letting people poorly benchmark your product and have every incentive to get it wrong.
I've never seen that credibly claimed. Why would their license ban benchmarking if their performance was any good?
By all means, run benchmarks on your workload profile and choose the technology that works best for you - that is perfectly OK. But not make claim that xxx beats oracle in yyy.
Oracle goal here is to make a good enterprise ready DB solution; not to fight the open-source community on hundreds of different performance claims, half of which have been specifically engineered to put the competing, leading product in a bad light.
You might not like what oracle does or how they do it, but it’s clear that they have a target on their back and sometimes the best way to play the game is not to play at all.
Just look at the « independent and fair review » that Top Gear made about Tesla.
Maybe. Or maybe it's to soak naive clients for all they're worth. The remedy for bad benchmarks is good benchmarks, not no benchmarks.
> Just look at the « independent and fair review » that Top Gear made about Tesla.
What about it? It was accurate and informative (unless you think Tesla lied about their range stats). The good points about electric cars are real but they don't mean we should ignore the downsides.
The comment you replied to just said Oracle allows running benchmarks internally, though.
The car did inform them it would run out of battery on the way. They made a segment about it and failed to inform the viewer that they had ignored several warnings given by the car before reaching the « oh no we are out of battery in the middle of nowhere » point.
This is not what I would qualify as a « fair review ». There are no « false claims » (they did run out of battery, after all !) but the information are given and presented in a way that paints the reviewed product in a specific light.
There are still quite a few enterprise workloads that only the likes of stuff like DB2 are a match for them.
This was based on my conversations with Chris Seaton before his passing, about 6 months ago.