Fibers are the right solution to improve Ruby performance

asyncio:

    import time
    import asyncio

    REPS = 1_000_000

    async def coro():
        for i in range(REPS):
            await asyncio.sleep(0)

    t0 = time.perf_counter()
    asyncio.run(coro())
    dt = time.perf_counter() - t0
    print(REPS / dt, 'reps/s')

asynker (https://github.com/enkore/asynker):

    import time
    import asynker

    REPS = 1_000_000

    async def coro():
        for i in range(REPS):
            await asynker.suspend()

    t0 = time.perf_counter()
    sched = asynker.Scheduler()
    sched.run_until_complete(coro())
    dt = time.perf_counter() - t0
    print(REPS / dt, 'reps/s')

The excellent curio (https://github.com/dabeaz/curio):

    import time
    import curio

    REPS = 1_000_000

    async def coro():
        for i in range(REPS):
            await curio.sleep(0)

    t0 = time.perf_counter()
    curio.run(coro())
    dt = time.perf_counter() - t0
    print(REPS / dt, 'reps/s')

Not that this number is hugely important.

if I remember correctly, Go's scheduler has a global queue and a local queue per worker thread, so when you spawn a goroutine it probably has to acquire a write lock on the global queue.

Allocating a brand new goroutine stack and doing some other setup tasks has a nontrivial overhead that has nothing to do with context switching, regardless of global locks.

To properly benchmark this, I think I would start with just measuring single task switching by measuring how long it takes main to call https://golang.org/pkg/runtime/#Gosched in a loop a million times. This would measure how quickly Go can yield a thread to the scheduler and have it be resumed, although this includes the overhead of calling a function.

Then I would launch a goroutine per core doing this yield loop and see how many switches per second they did in total, and then launch several per core, just to ensure that the number hasn't changed much from the goroutine per core measurement.

Since Go's scheduler is not bound to a single core, it should scale pretty well with core count.

I might run this benchmark myself in awhile, if I find time.

But this is beyond the scope of the article.

Grinding another 5x out of a flat profile can be hard work requiring more creativity and producing less readable code than a (fairly mechanical) translation. Luckily these tasks also tend to crop up when design has stabilised and team sizes are increasing, meaning it can often coincide with the benefits of static typing becoming greater.

It's not a panacea, and it's obviously both risky and costly. Shrugs.

(I've also seen the other case, FWIW. Wrote some C extension code called from a Rails app, and it was the right call at the time and we got great mileage out of it.)

Guilds felt omitted in your post since they (should) address one of the points you make about the usability/ergonomics of existing Ruby APIs for managing non-sequential execution.

But it’s definitely a bit early to tell what Guilds will actually look like as a final product.

I could be wicked wrong though, it's been a long while since I futzed with fibers.

Any time you call a blocking function that the system provides, it should immediately yield the fiber, which makes it look preemptive. If you write a loop that just spins forever, that could block the whole system, potentially, making the abstraction leaky. In a language like Ruby, they could definitely add some true preemption, but I don't know if that's what they plan to do.

From the article: "Fibers, on the other hand, are semantically similarly to threads (excepting parallelism), but with less overhead." So, the author definitely isn't implying parallelism of the fibers.

> What's all the fuss about paralllelism in the article about then?

The author was talking about different methods for handling more than one request at a given time, which include forking and threads. With Ruby's GIL, threads are a lot less attractive than they could be. A good fiber implementation can handle tons of network requests concurrently and very efficiently even on a single core, which is the case being discussed here.

At the end, the author discusses a hybrid approach of forking and fibers, where each processor core would have a fork of the Ruby program running, and each fork would have its own fiber pool, running many tasks concurrently.

In languages that don't have a GIL, forking is rarely a tool that I reach for. It really hurts your database pooling and all sorts of other small problems, but it's a common trade-off when using Ruby, Python, and Node.

https://en.wikipedia.org/wiki/Coroutine