Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.2’s YJIT is Production-Ready

shopify.engineering

Post reply on HN
Print view View original

221–230 of 304 posts

Re: Ruby 3.2’s YJIT is Production-Ready

#221

Post by brightball »

jeltz wrote: post #197
kenhwang wrote: post #155

Earlier quoted context omitted.

And by many accounts Oracle makes the fastest database yet everyone still uses Postgres. 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.

I have only seen one set of benchmarks, apparently posted by someone willing to tempt fate by violating the benchmark ban of the license, which compared them and in those PostgreSQL crushed Oracle. Of course those could have been misleading or straight up lies but it is not at all a known fact that Oracle has better performance than PostgreSQL. And the database consultants I know who have worked on both seem to think…

Yea, I’ve always seen Oracle’s big selling point is the admin tooling that they provide. At least that’s what I’ve been told.

Re: Ruby 3.2’s YJIT is Production-Ready

#222

Post by IMTDb »

lmm wrote: post #183
kenhwang wrote: post #155

Earlier quoted context omitted.

And by many accounts Oracle makes the fastest database yet everyone still uses Postgres. 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.

> by many accounts Oracle makes the fastest database I've never seen that credibly claimed. Why would their license ban benchmarking if their performance was any good?

Their licensing does not ban benchmarking; it only bans publishing the results. A subtle but important point.

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.

Re: Ruby 3.2’s YJIT is Production-Ready

#223

Post by esprehn »

JohnBooty wrote: post #135
acchow wrote: post #132

I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?

Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. 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)

You have his name slightly wrong, it was Chris Seaton.

Here was the announcement:

https://twitter.com/flavorjones/status/1600436490885947393

Re: Ruby 3.2’s YJIT is Production-Ready

#224

Post by seti0Cha »

brightball wrote: post #221
jeltz wrote: post #197

Earlier quoted context omitted.

I have only seen one set of benchmarks, apparently posted by someone willing to tempt fate by violating the benchmark ban of the license, which compared them and in those PostgreSQL crushed Oracle. Of course those could have been misleading or straight up lies but it is not at all a known fact that Oracle has better performance than PostgreSQL. And the database consultants I know who have worked on both seem to think…

Yea, I’ve always seen Oracle’s big selling point is the admin tooling that they provide. At least that’s what I’ve been told.

I've always seen their big selling point as it being required by other giant software packages. At least that's the way it threatened to enter burrow into various places I've worked.

Re: Ruby 3.2’s YJIT is Production-Ready

#225

Post by daviding »

I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down quickly), and the first issue is that a lot of the 'easy to deploy is a feature' PAAS platforms is that they bill by web/worker size restricted by memory rather than just pure virtual CPU power. Render etc all does this as well, and the memory headrooms are low.

This means that you often have to deal with, say 512 MB per instance, and then if using something like Puma, have to work out how to split concurrency vs memory footprint. What I'm finding is that v3.2 YJIT loves memory, so I have to trade off that, which means less concurrency per process. Benchmarking it quickly, the 15% gains I might get on the thread aren't worth having to move to just 2 threads on a 512 MB instance versus the 3 threads I can get with YJIT not enabled.

I think it's really neat and will continue to track it, but the performance in terms of memory trade-off isn't there quite as yet for our app profile. Not sure if others will find the same, but I guess its if their production environments aren't PAAS's with low memory headroom or not.

Re: Ruby 3.2’s YJIT is Production-Ready

#226

Post by SirGiggles »

samsquire wrote: post #215

This is awesome. I am impressed. I recently wrote a toy compiler for x86_64. I use an external assembler. My dream is to write a JIT compiler runtime. https://GitHub.com/samsquire/compiler My understanding is that you generate machine code and then mprotect the code to be executable then jump to the void * as a function pointer to execute generated instructions. What I would like to understand more is tracing compile…

That looks so cool.

Do you have any resources you would recommend to someone who want's to explore (or develop as you have) in this subject?

Re: Ruby 3.2’s YJIT is Production-Ready

#227

Post by ewalk153 »

brigandish wrote: post #208
xfalcox wrote: post #175

Earlier quoted context omitted.

You can enable YJIT and get a ~30% speedup by passing an extra environment variable to your Docker container. Moving away from CRuby to an alternative Ruby is a lot harder than that. Also Oracle.

> Moving away from CRuby to an alternative Ruby is a lot harder than that. 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.

From the Truffleruby repo [1]:

> 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.

[1] https://github.com/oracle/truffleruby

Re: Ruby 3.2’s YJIT is Production-Ready

#228

Post by jerf »

lmm wrote: post #186
jerf wrote: post #105

Earlier quoted context omitted.

Static typing was a nightmare (by modern standards) in the 1990s. Dynamic scripting languages were such a breath of fresh air that we were willing to pay the steep performance penalties without hardly a thought. Sort of like the saying "deleted code is debugged code", code that you actually write always performs better than the code you didn't write because it was too soul-sucking. But static typing languages, librar…

Actually almost all the stuff that's gone mainstream in the last 30 years was already around in the '90s if you used OCaml (or indeed Haskell). But in fairness not many people did.

Even the languages that were painful in the 1990s have gotten better. Some of it was the system libraries, some was just the lack of experience in API design, some was just a lack of awareness that better was even possible. While I don't like C++ at all, certainly C++ in 2023 is a lot more tolerable than C++ in 1997.

I learned programming in the late 1990s. Looking at Windows programming at the time looking like gibberish to me and I looked forward to the day I would understand it. Honestly, it still looks like gibberish to me. I understand the whys and the wherefores better now and if I had no choice, yeah, I could learn it and write it, but the code from that still reads absolutely awfully to me, just unbelievably bad by almost every modern standard. Even when you're writing approximately equivalent code in C# at the same low level of acquiring handles and manipulating them with very low level APIs, it's just so much better now.

Re: Ruby 3.2’s YJIT is Production-Ready

#229

Post by gtirloni »

earthnail wrote: post #153
pantulis wrote: post #63

Earlier quoted context omitted.

Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.

There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve. And so Ruby may scale in cpu performance, but not with your number of teams. That’s why Spotify switched to Java (I think they were a heavy Python user before that, not Ruby, but not sure anymore - but the organisational problem is the same for those two). Note that I still choose Rail…

> There are organisational scaling issues that you may hit with a language like Ruby that strongly typed languages like Java can solve.

Such as?

Re: Ruby 3.2’s YJIT is Production-Ready

#230

Post by pdntspa »

stevebmark wrote: post #71
pdntspa wrote: post #54

Earlier quoted context omitted.

I am sooooooooooo sick of all this language churn. Ruby is a fantastic language, full stop.

irb > def method irb > 'yes' irb > def method irb > 'it is not' irb > end irb > end irb > method => :method irb > method => "it is not"

yeah don't nest your methods. When have I ever needed that anyway?
Post reply on HN