Hacker News Reader

Comment by slashdev | Hacker News Reader

The whole point of IO uring is to be fast by reducing the number of system calls per request.

If you then process your requests in the slowest programming language, you add back at least 100x the overhead.

It doesn’t make sense to me.

Just this morning I was benchmarking the example HTTP server I wrote using IOU [0]. The usual caveats notwithstanding, I would say 100K sustained requests per second serving 1024 concurrent connections (on a more-or-less average laptop) is anything but slow...

In fact, the whole idea for this library is to provide a low-level, fast, flexible, asynchronous I/O layer for building Ruby apps and letting Ruby+YJIT optimize the app code, which it actually is getting pretty good at.

If you're open to learning more about where the Ruby runtime is performance-wise, there was a very interesting recent talk [1] about this very subject.

[0] https://github.com/digital-fabric/iou/blob/main/examples/htt... [1] https://www.youtube.com/watch?v=qf5V02QNMnA

As soon as you do more than hello world inside those requests, I think you'll find the difference is hardly noticeable. Try it with real requests that use the database.

We get it, you vape.

The "performance" of the language is going to have approximately zero effect once a request has to schlep over to the database in a 7ms round-trip.

There's a wide field of applications where language performance has approximately zero effect on application performance. I have 15ms of latency, what do I care if your web app is written in Rust?

I expected this comment, just not so early in the life of this thread. Moving on... cool stuff!

It shouldn't have been flagged though—what's up with that? Why would someone, let alone multiple people, flag OP's comment? It's inoffensive, doesn't violate guidelines whatsoever, and in fact asks a question that I'm sure many people (myself included) feel is quite worthy of asking, so we can read peoples' responses to it.

Using flags to shut down entirely reasonable discussion is very lame.

This whole forum is becoming quite lame. I just haven’t found a better one yet.

Probably because it’s a fairly tired argument that gets rolled out almost automatically in response to any async-IO or high speed IO work. It’s like there’s a group that likes to argue that only the cream of the crop spills get to use nice new things, and the rest of us spills be pleased with what we have already. At this point, it’s a bit “ok thank you”, it don’t add much.

You are not describing a use-case that the flagging feature on this website is intended to be used for—flags are not super-downvotes.

I'm aware, but give people a proxy for something like downvotes, and they'll use them as such. Hackernews tends to have more restraint than reddit on that front, but not immune.

One way you can think of this is speeding up the "slowest programming language". And removing/reducing blocking calls has benefits for languages like Ruby too.

I found the easiest way to explain it is Ruby/Python/Lua are scripting languages for optimized C code.

A syscall is so fast compared to Ruby code. It really doesn’t make much sense to me.

Io uring have several use cases. You describe one, but it also enables things like no blocking file IO, which nothing else provides in a useful manner. Ruby can be slow in certain scenarios, but not slow enough that things like that doesxnt matter.

Well that’s true. To do async file IO without that is really just using a thread pool.

Of course, I don’t see why that won’t perform fine for Ruby.

It’s just so slow that optimizing the async IO at the OS level doesn’t matter

The slower the language the bigger the upside.

That’s false.

If the difference between IO uring and epoll is 2x, but that was only 5% of the total runtime, the rest being slow Ruby code, then at best you get a 2.5% speed up. Not worth it.

Oh, that meme is old, sorry to say. Here's a nice blog post about ruby outperforming C with the new JIT compiler. Fun times :)

https://railsatscale.com/2023-08-29-ruby-outperforms-c/

Ruby YJIT is slower by multiple orders of magnitude if we look at more than a single constructed example.

In addition, the blog post measures the cost of avoiding doing the interop, which allows wins as the compiler improves in the case of short-lived calls implemented in a native component.

This, however, is not exclusive to Ruby and statically typed JIT or AOT compiled languages benefit from this to a much higher extent.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

In very specific, very limited cases.

I remember when these claims were made for Java twenty years ago. It’s still slower than C, most of the time.

Some things don’t change.

Reply on news.ycombinator.com