Hacker News Reader

Comment by internetter | Hacker News Reader

"write as much Ruby as possible, especially because YJIT can optimize Ruby code but not C code"

I feel like I'm not getting something. Isn't ruby a pretty slow language? If I was dipping into native I'd want to do as much in native as possible.

View on HN

There was a little drama that played out as Java was getting a proper JIT.

In one major release, there was a bunch of Java code responsible for handling some UI element activities. It was found to be a bottleneck, and rewritten in C code for the next major release.

Then the JIT became properly useful, and the FFI overhead was more than the difference between the hand-tuned C code and what the JIT would spit out on its own. So in the next major release, they rolled back to the all-Java implementation.

Java had a fairly reasonably fast FFI for that generation of programming language, but they swapped for a better one a few releases after that. And by then I wasn't doing a lot of Java UI code so I had stopped paying attention. But around the same time they were also making a cleaner interface between the platform-specific and the general Java code for UI, so I'm not entirely sure how that played out.

But that's exactly the sort of see-sawing you need to at least keep an eye out for when doing this sort of work. Would you be better off waiting a couple milestones and saving yourself a bunch of hand-tuning work, or do you need it right now for political or technical reasons?

That is where a JIT enters the picture, ideally a JIT can re-optimize to an ideal state.

While this is suboptimal when doing one shot execution, when an application is long lived, mostly desktop or server workloads, this work pays off versus the overall application.

For example, Dalvik had a pretty lame JIT, thus it was faster calling into C for math functions, eventually with ART this was no longer needed, JIT could outperform the cost of calling into C.

https://developer.android.com/reference/android/util/FloatMa...

Depending on the math (this is a hedge) you need, FORTRAN is probably faster still. Every time I fathom a test and compare python, fortran, and C, Fortran always wins by a margin. Fortran:C:Python 1:1.2:1.9 or so. I don't count startup I only time time to return from function call.

Most recently I did hand-looped matrix math and this ratio bore out.

I used gfortran, gcc, and python3.

Sure, but that doesn't fit the desktop or server workloads I mentioned, I guess we need to except stuff like HPC out of those server workloads.

I would also add that modern Fortran looks quite sweet, the punched card FORTRAN is long gone, and folks should spend more time learning it instead of reaching out to Python.

When dealing with a managed language that has a JIT or AOT compiler it's often ideal to write lots of stuff in the managed language, because that enables inlining and other optimizations that aren't possible when calling into C.

This is sometimes referred to as "self-hosting", and browsers do it a lot by moving things into privileged JavaScript that might normally have been written in C/C++. Surprisingly large amounts of the standard library end up being not written in native code.

Oh, I am indeed surprised! I guess I always assumed that most of the JavaScript standard library was written in C++

Well, most all of the compiler, runtime, allocator, garbage collector, object model, etc, are indeed written in C++ And so are many special operations (eg crypto functions, array sorts, walking the stack)

But specifically with regards to library functions, like the other commentator said, losing out on in lining sucks, and crossing between JS and Native code can be pretty expensive, so even with things like sorting an array it can be better to do it in js to avoid the overhead... Eg esp in cases where you can provide a callback as your comparator, which is js, and thus you have to cross back into js for every element

So it's a balancing game, and the various engines have gone back and forth on which functions are implemented in which language over time

Much of the standard library in v8 is written in Torque, a custom language.

https://v8.dev/docs/torque

Example file for array.find(…): https://github.com/v8/v8/blob/5fe0aa3bc79c0a9d3ad546b79211f0...

Ruby has realized this as well. When running in YJIT mode, some standard library methods switch to using a pure ruby implementation instead of the C implementation because the YJIT-optimized-ruby is better performing.

FFI presents an opaque, unoptimizable boundary of code. Having chatty code like this is going to cost a lot. To the point where this is even a factor in much faster languages with zero-cost-ish interop like C# - you still have to make a call, sometimes paying the cost of modifying state flags for VM (GC transition).

If Ruby YJIT is starting to become a measurable factor (after all, it was slower than other, purely interpreted, languages until recently), then the same rule as above will become more relevant.

There's a phenomenal breakdown by JPCamara (https://jpcamara.com/2024/12/01/speeding-up-ruby.html) on why the Ruby#each method was rewritten in Ruby (https://bugs.ruby-lang.org/issues/20182). And bonus content from tender love: https://railsatscale.com/2023-08-29-ruby-outperforms-c/.

TL;dr - JIT rules.

If FFI calls are slow (even slower than Ruby -> Ruby calls) then informs the way you use native code. You look for workflows whereby frequent calls to a FFI function are avoided: e.g. large number of calls in some inner loop. Suppose such a situation cannot be avoided. Then you may have no recourse than to move that loop out of Ruby into C: create a custom FFI for that use case which you can call once and have it execute the loop, calling many times the function you really wanted to call.

If the FFI call can be made faster, maybe you can keep the loop in Ruby.

Of course that is attractive to people writing an application in Ruby.

That's how I interpret keeping as much code Ruby as possible.

Nobody in their right mind wants to add additional application-specific jigs written in C just to use some C piece.

Once you start doing that, why even have FFI; you can just create a module.

One attractive point about FFI is that you can take some C library and use it in a higher level language without writing a line of C.

It's been fast for a while now.

Even a 50% or 2x speed improvment still make it a pretty slow language. It's in the Python range.

What is fast here? Ruby has usually been about 1/150th the speed of C.

If the code JITs well, Ruby performs somewhere between Go and NodeJS. Without the JIT, it's similar to Lua.

If the code JITs well

What does this mean? Any JIT can make a tight loop of math and arrays run well but that doesn't mean a typical program runs well.

For Ruby, it's code where variables and method input/return types can be inferred to remain static, and variable scope/lifetime is finite. From my understanding, much of the performance gain was from removing the need for a lot of type checking and dynamic lookup/dispatch when types were unknown.

So basically, writing code similarly to a statically typed compiled language.

Node uses V8 which has a very advanced JIT compiler for the hot code, which does a lot of optimizations for reducing the impact of JS's highly dynamic type system.

The claim that Ruby YJIT beats this is not supported by the data to put it mildly:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (scroll down on each submission and you will see it uses YJIT)

(and Go is not a paragon of absolute performance either)

Not at all saying Ruby's compiler is more capable, more that typical Ruby code is easier to optimize by their JIT design than typical JS, largely because Ruby's type system is more sane.

The whitepapers that inspired Ruby's JIT was first tested against a saner subset of JS, and shown to have some promising performance improvement. The better language/JIT compatibility is why the current Ruby JIT is actually showing performance improvements over the previous more traditionally designed JIT attempts.

JS can get insanely fast when it's written like low level code that can take advantage of its much more advanced compiling abilities; like when it's used as a WASM target with machine generated code. But humans tend to not write JS that way.

Agreed about Go as well, it tends to be on the slow side for compiled languages. I called it out not as an example of a fast language, but because it's typical performance is well known and approximately where the upper bound of how fast Ruby can get.

I did a quick search for the white papers and couldn't find them. Would you be kind enough to leave a link or a title? It sounds interesting, I'd like to read more.

I believe this is the paper that started it all (there are a couple of follow up papers): https://arxiv.org/pdf/1411.0352v1

The author was eventually hired to develop YJIT.

To add some nuance to the word "fast."

When we optimize Ruby for performance we debate how to eliminate X thousand heap allocations. When people in Rust optimize for performance, they're talking about how to hint to the compiler that the loop would benefit from SIMD.

Two different communities, two wildly different bars for "fast." Ruby is plenty performant. I had a python developer tell me they were excited for the JIT work in Ruby as they hoped that Python could adopt something similar. For us the one to beat (or come closer to) would be Node.js. We are still slower then them (lots of browser companies spent a LOT of time optimizing javascript JIT), but I feel for the relative size of the communities Ruby is able to punch above its weight. I also feel that we should be celebrating tides that raise all ships. Not everything can (or should be) written in C.

I personally celebrate any language getting faster, especially when the people doing it share as widely and are as good of a communicator as Aaron.

Has it? I thought Ruby was pretty much the benchmark for the slowest language. What is it faster than?

Python. At least, it was a few years ago. Both languages have added JIT compilers since then, so I’m not sure how the most recent versions compare.

I see some people say this but I’ve never seen a benchmark support that if you include performance-focused distributions like pypy.

https://programming-language-benchmarks.vercel.app/amp/pytho...

Is there somewhere with benchmarks that supports the idea that Ruby is faster than Python?

Fair point, I was specifically referring to the CPython interpreter. I don’t know if there’s a benchmark that compares PyPy to JIT-compiled Ruby.

Looks the the one at that link does unless there's some newer versioning thing I'm not aware of. The top results seem to be comparing pypy 3.10.14 and ruby/yjit 3.4.1.

Because unfortunately PyPy is largely ignored by the community , despite their heroic efforts.

I’ve only seen a handful of people use it for local development but I’ve seen plenty of people use it for servers in production. Look like the latest cpython has a JIT built in. It would be cool if it saw the same gains that ruby did.

It is pretty much early days, you are supposed to compile your own CPython to enable it.

Python

Tcl, Vbscript, bash/sh.

Tcl had it’s web moment during the first dot com era within AOLserver.

Not only, you are missing Vignete, and our own Safelayer (yes I know it isn't public).

However exactly because of the experience writing Tcl extensions all the time for performance, since 2003 I no longer use programming languages without JIT/AOT other than for scripting taks, or when the decision is external.

The founders at our startup went on to create OutSystems, with many of the learnings, but using .NET instead, after we were given access to .NET during its "Only for MSFT partners eyes" early state.

Reply on news.ycombinator.com