It’s more like goroutines or other lightweight concurrency mechanisms. If threads are OS-level concurrency primitives, fibers are scheduled within Ruby itself, which makes them much more efficient than threads.<p>In fact, I got the following results in HTTP benchmark tests:<p>Go:<p>* Latency under stable load: p95 0.25–5.32 ms, p99 2.20–9.92 ms
* Memory: 23–31 MB RSS across HTTP scenarios<p>Ruby:<p>* Latency under stable load: p95 1.03–6.45 ms, p99 2.32–8.30 ms
* Memory: 84–295 MB RSS, depending on the scenario<p>Fibers can also handle WebSockets better because WebSocket workloads involve more I/O waiting.<p>A typical Falcon setup uses N workers, one thread per worker, and many fibers. Since the fibers are cooperatively scheduled within a single thread, this avoids much of the context-switching overhead associated with OS threads. Multiple workers can still run in parallel across CPU cores.
To dig a bit into why fibers are more efficient than threads.<p>The OS has a rather opaque view on what happens in a thread. It doesn't know how the memory is used or what memory is efficient. The OS can block a thread when it runs into IO, but it doesn't know or care about what other threads in an application it can or should activate.<p>Fibers bring the threading into the application layer. While the application can't choose which and when a thread runs, it can make choices about which fibers to run. Further, the application knows intimate details about things like the stack of a given thread. When it goes to park a fiber, it knows just how much memory should be saved off so the fiber can resume and it doesn't have to save off all the memory allocated to a thread's stack. Further, because so many programs are stack based an application can pretty smartly save and reuse segments of the stack which are common amongst fibers. So, for example, if you spin off 1000 fibers at one location in code, the stack for those 1000 fibers will be identical right up until the fiber starts executing.<p>The main drawback of fibers is they can't implement things like fair scheduling. Applications have few ways to park a currently running fiber to let another one run if, for example, the app wants to make some progress on all the fibers alive. The app has to wait for the fiber to hit some sort of IO point in the code or insert explicit park checks (The JVM actually does this for GC purposes. It creates "safepoints" which application threads make a quick check to see if the JVM wants to start a GC). The OS has more power here, it can simply interrupt the thread and start running something else for a given quanta.
How much load? How many concurrent connections? What machine? Don’t get me wrong, benchmarks like these are useful to help ballpark performance floors, but really only relevant for a given load scenario. They don’t mean a lot without context. Not an attack by the way, just feedback.
I'm unclear on the relevance of a comparison between Go and Ruby here. Ruby is radically slower than Go. It's down there with Python, if not a touch behind [1]. From the outside, I'd expect that it's possible that slight improvements in the context switching time will be dwarfed by the generally slow execution of Ruby itself; that is, if Ruby is going to take 100 microseconds to do something, whether it context switches in 1 microsecond (best-case OS thread cost) or .2 microseconds (best-case goroutine switch) is of somewhat less consequence then it is for a compiled langauge that can complete that task in 2 microseconds. That ratio of 50x is not just something I made up, it's about what you can expect in general. I'd need to see the actual Ruby benchmarks to come to any conclusions as to whether or not I'm right.<p>The other problem with this sort of benchmark, which is a mistake I also commonly see made by Node developers, is that the Ruby HTTP stack has significant native code in it, like: <a href="https://github.com/puma/puma/tree/main/ext/puma_http11" rel="nofollow">https://github.com/puma/puma/tree/main/ext/puma_http11</a> This is a good and proper thing that brings benefits to all involved; it's not like it's "cheating" or anything, it's a real performance benefit. But it does mean when you're benchmarking a simple HTTP server, you're benchmarking Ruby <i>qua</i> Ruby a lot less than you think you are, and so the relevance of such benchmarks to codebases that have actual Ruby in them will be less.<p>[1]: <a href="https://programming-language-benchmarks.vercel.app/python-vs-ruby" rel="nofollow">https://programming-language-benchmarks.vercel.app/python-vs...</a>
It was mostly HTTP/JSON tests with some sort of validation, basic auth and logging. I think Ruby is used the most for this. I see many companies switching from Ruby to Go or FastAPI for this basic web services stuff, and I have no idea why. Ruby needs to improve its memory management, but the speed is pretty good.
I think the GP just showed that in a particular scenario, Ruby isn’t “radically slower” than Go. So how is the comparison not relevant?