Concurrence & le GVL, ou attente contre calcul Concurrency & the GVL, or waiting versus computing

Le GVL : un seul thread exécute du Ruby — l'attente, pas le calcul, se chevauche.The GVL: one thread runs Ruby — waiting, not computing, overlaps.

Le dernier coût, et le plus mal compris. En MRI — l'implémentation de référence — un verrou global, le GVL, garantit qu'un seul thread exécute du code Ruby à la fois. Conséquence frontale : des threads ne parallélisent pas le calcul. Lancer quatre threads sur un calcul CPU ne va pas quatre fois plus vite ; le GVL les fait passer chacun leur tour. Mais le GVL est relâché pendant les attentes — un appel réseau, une lecture disque, un sleep. Là, les threads brillent : pendant qu'un thread attend la réponse d'un serveur, un autre peut lancer sa requête. La question n'est donc jamais « threads ou pas » dans l'absolu, mais « mon goulot est-il de l'attente ou du calcul ? ».The last cost, and the most misunderstood. In MRI — the reference implementation — a global lock, the GVL, guarantees that only one thread runs Ruby code at a time. The frontal consequence: threads don't parallelize computation. Launching four threads on a CPU task doesn't go four times faster; the GVL takes them in turns. But the GVL is released during waits — a network call, a disk read, a sleep. There, threads shine: while one thread waits for a server's response, another can fire its request. So the question is never 'threads or not' in the absolute, but 'is my bottleneck waiting or computing?'.

# en MRI, le GVL (Global VM Lock) : UN seul thread exécute du Ruby à la fois
def fib(n) = n < 2 ? n : fib(n - 1) + fib(n - 2)

# CPU-bound : 4 threads ne vont PAS plus vite — le GVL les sérialise
ts = 4.times.map { Thread.new { fib(33) } }
ts.each(&:join)                  # ≈ aussi lent que 4 fib(33) en série

# I/O-bound : 4 threads VONT plus vite — le GVL est libéré pendant l'attente
urls = [...]                     # 4 requêtes réseau
ts = urls.map { |u| Thread.new { Net::HTTP.get(URI(u)) } }
ts.map(&:value)                  # les attentes se CHEVAUCHENT

Quatre threads sur un calcul : aucun gain. Sur de l'attente : quadruple.Four threads on a computation: no gain. On waiting: fourfold.

La surprise qui désarçonne tout le monde une fois. On apprend que « les threads accélèrent », on en met quatre sur un calcul lourd, on chronomètre… et c'est aussi lent qu'en série, parfois pire. Le GVL a fait passer les quatre threads chacun leur tour : il n'y a jamais eu deux calculs en même temps. Bascule maintenant sur de l'I/O — quatre requêtes réseau — et le même code à quatre threads va presque quatre fois plus vite, parce que le GVL se libère à chaque attente et laisse les temps morts se superposer. Même outil, résultats opposés, selon une seule chose : le goulot. Et la seule façon de le savoir, fidèle au volume, c'est de mesurer les deux.The surprise that throws everyone once. You learn 'threads speed things up', you put four on a heavy computation, you time it… and it's as slow as serial, sometimes worse. The GVL took the four threads in turns: there were never two computations at once. Now switch to I/O — four network requests — and the same four-thread code goes nearly four times faster, because the GVL releases on each wait and lets the dead times overlap. Same tool, opposite results, by one thing: the bottleneck. And the only way to know, true to the volume, is to measure both.

require "benchmark"
def crunch = (1..5_000_000).sum { |i| Math.sqrt(i) }

# en série
serial = Benchmark.realtime { 4.times { crunch } }

# « parallélisé » avec 4 threads
threaded = Benchmark.realtime do
  4.times.map { Thread.new { crunch } }.each(&:join)
end

serial    # => ~1.6 s
threaded  # => ~1.6 s (parfois PIRE) — le GVL a sérialisé les 4 calculs
#           les threads se sont relayés, pas superposés. Zéro gain CPU.

Le calcul est du Ruby pur : à aucun instant le GVL n'est relâché, donc les quatre threads se relaient sur un seul cœur. Le total ne bouge pas — et le coût du va-et-vient entre threads peut même le rendre plus lent. C'est le contre-pied du chapitre suivant : Thread sur du CPU est une fausse parallélisation.The computation is pure Ruby: the GVL is never released, so the four threads take turns on a single core. The total doesn't move — and the cost of switching between threads can even make it slower. It's the next chapter's counter-take: Thread on CPU is a fake parallelization.

Les deux chronos ci-dessus se lisent ; celui-ci se fabrique. Un seul curseur sépare les deux cas — la part d'attente d'une tâche. Mets-la à 0 %, monte les workers, et regarde l'accélération descendre sous ×1 : c'est le premier bloc de code, en direct. Remonte-la à 80 % sans toucher aux workers : c'est le second. Les presets sont des réglages déjà faux ; ensuite pousse les curseurs pendant que ça tourne, la simulation ne repart pas de zéro.The two timings above are read; this one you make. A single slider separates the two cases — a task's share of waiting. Set it to 0%, push the workers up, and watch the speed-up drop below ×1: that's the first code block, live. Raise it back to 80% without touching the workers: that's the second. The presets are settings already wrong; then push the sliders while it runs, the simulation doesn't restart.

Files idéales, pas d'ordonnanceur, pas de cache : le modèle est juste sur le sens des pentes, pas sur les chiffres. Aucune valeur d'ici ne se recopie dans un dimensionnement — c'est ta propre application qu'il faut mesurer, et c'est tout le propos du volume.Ideal queues, no scheduler, no cache: the model is right about the direction of the slopes, not about the numbers. Nothing here transfers to a capacity plan — it's your own application you have to measure, and that's the whole point of this volume.

Quatre outils, un critère : attendre (thread, fiber) ou calculer (ractor, process).Four tools, one criterion: wait (thread, fiber) or compute (ractor, process).

Le goulot identifié, l'outil suit. Pour de l'attente : Thread suffit le plus souvent — simple, supporté partout, le GVL se libère pendant l'I/O. Pour beaucoup d'I/O concurrentes (des milliers de connexions), les Fibers avec un scheduler — la gem async — offrent une concurrence coopérative ultra-légère sur une seule thread OS. Pour du calcul : il faut sortir du GVL. Les Ractors (Ruby 3) donnent un vrai parallélisme dans le process, au prix d'une contrainte que tout le Vol 4 a préparée — aucune mémoire mutable partagée, les objets échangés sont copiés ou figés. Les processus (fork) parallélisent sans partage du tout, mémoires séparées, au prix de la duplication et de l'IPC. Un critère, quatre réponses.With the bottleneck identified, the tool follows. For waiting: Thread is usually enough — simple, supported everywhere, the GVL releases during I/O. For many concurrent I/Os (thousands of connections), Fibers with a scheduler — the async gem — offer ultra-light cooperative concurrency on a single OS thread. For computing: you must leave the GVL. Ractors (Ruby 3) give true in-process parallelism, at the price of a constraint all of Vol 4 prepared — no shared mutable memory, exchanged objects are copied or frozen. Processes (fork) parallelize with no sharing at all, separate memories, at the cost of duplication and IPC. One criterion, four answers.

# I/O-bound → faire chevaucher les attentes

# Thread : concurrence d'attente, simple, partout
urls.map { |u| Thread.new { fetch(u) } }.each(&:value)

# Fiber + scheduler (gem async) : des MILLIERS d'I/O concurrentes, léger
require "async"
Async do
  urls.each { |u| Async { fetch(u) } }   # coopératif, une seule thread OS
end

# CPU-bound → exécuter VRAIMENT en parallèle, hors GVL

# Ractor : parallélisme dans le process, SANS mémoire mutable partagée (Vol 4)
rs = 4.times.map { Ractor.new { heavy_compute } }
rs.map(&:value)            # 4 cœurs, pour de vrai — les objets passés sont
                           # copiés ou figés : pas d'état partagé, pas d'aliasing
                           # (#value depuis Ruby 4.0 ; #take en Ruby 3.x)

# Processus (fork) : parallélisme total, mémoires séparées
readers = 4.times.map do
  r, w = IO.pipe
  fork { w.write(Marshal.dump(heavy_compute)); w.close }
  r
end

Un dernier recours quand le calcul est vraiment le mur : changer d'implémentation. JRuby et TruffleRuby n'ont pas de GVL et parallélisent les threads pour de bon ; le YJIT de MRI accélère le code chaud sans rien changer au modèle. Mais — refrain du volume — on ne dégaine rien de tout cela sans un profil qui montre que le CPU, et lui seul, est le goulot.A last resort when computation is truly the wall: change implementation. JRuby and TruffleRuby have no GVL and parallelize threads for real; MRI's YJIT speeds up hot code with no change to the model. But — the volume's refrain — you reach for none of this without a profile showing that the CPU, and it alone, is the bottleneck.

Des threads sur un calcul CPU — et l'étonnement que ça n'aille pas plus vite.Threads on a CPU computation — and the surprise it isn't faster.

Le contre-exemple obligatoire, et le contre-pied le plus frontal de la série. Une tâche est lente — un traitement d'images, un calcul lourd — alors on découpe en quatre et on lance quatre threads, certain de diviser le temps par quatre sur une machine multicœur. On mesure : rien n'a changé. C'était du CPU pur, et le GVL a fait passer les quatre threads chacun leur tour. On a ajouté de la complexité, et le risque de bugs de partage mutable (Vol 4), pour un gain nul — exactement le mauvais outil pour le bon problème. Le calcul ne se parallélise qu'en sortant du GVL : Ractors ou processus. Mais avant même de changer d'outil, le réflexe du volume : profiler pour confirmer que le goulot est bien le CPU, pas une attente déguisée.The mandatory counter-example, and the series' most frontal counter-take. A task is slow — image processing, a heavy computation — so you split it in four and launch four threads, certain you'll divide the time by four on a multicore machine. You measure: nothing changed. It was pure CPU, and the GVL took the four threads in turns. You added complexity, and the risk of shared-mutation bugs (Vol 4), for zero gain — exactly the wrong tool for the right problem. Computation parallelizes only by leaving the GVL: Ractors or processes. But before even changing tools, the volume's reflex: profile to confirm the bottleneck is really the CPU, not a disguised wait.

# Piège : « j'ajoute des threads pour que ce calcul aille plus vite »
def render_thumbnails(images)
  images.each_slice(images.size / 4).map do |batch|
    Thread.new { batch.each { |img| resize_and_filter(img) } }  # CPU pur
  end.each(&:join)
end

# on s'attend à ÷4 sur une machine 4 cœurs… et le temps ne bouge pas.
# resize_and_filter est du calcul Ruby : le GVL sérialise les 4 threads.
# on a ajouté de la complexité (et des bugs de partage) pour ZÉRO gain.

# Le CPU se parallélise hors GVL : Ractor (ou processus)
def render_thumbnails(images)
  images.each_slice(images.size / 4).map do |batch|
    Ractor.new(batch) { |b| b.map { |img| resize_and_filter(img) } }
  end.flat_map(&:value)        # 4 cœurs RÉELLEMENT occupés (#take en 3.x)
end

# mais d'abord : MESURER que le goulot est bien le CPU, pas le décodage I/O.
require "benchmark"
Benchmark.realtime { render_thumbnails(images) }   # avant / après, on compare