Everything You Know About the GIL is Wrong
summary
Claim: the GIL doesn't stop Ruby from doing useful concurrency; benchmarks show a 10x speedup on I/O-bound tasks by firing 20 Concurrent Ruby futures into a thread pool, with MRI beating JRuby and Rubinius on that case. Demos include serial vs concurrent benchmarks and a contrived read‑update race that exposes that the GIL protects the interpreter not user code. Conclusion: Ruby handles concurrent I/O well but MRI's GIL prevents CPU-bound parallelism.
AI-written summary · about
chapters (19)
- 0:00Intro
- 1:40Creator - Concurrent Ruby
- 3:26According to the Internet
- 9:38THE INTERNET JUST LIED TO ME
- 11:13Channeling my inner Rob Pike
- 12:05Concurrency vs. Parallelism
- 14:11What is a thread?
- 16:19Multithreading in the OS
- 17:20Getting back to the GIL
- 19:48Implications of the GIL Only one unit of Ruby code can execute at any
- 20:56The obligatory word definition
- 23:17Correct vs. safe
- 25:12Ruby is selfish
- 27:11Ruby is thread safe, your code isn't
- 27:47Memory model
- 36:28Lack of knowledge
- 37:51Concurrency in Ruby isn't perfect
- 40:28Tools of the trade
- 44:07Summary
related talks
25mWhat does GIL really guarantee you?
23mParallel Processing With Ruby
33mConcurrency for !Dummies (Who Don't Get It (...Yet))
28mConcurrency for Rubyists
33mDear God What Am I Doing? Concurrency and Parallel Processing
35mIn defence of GVL
20mSubprocesses, Threads and Fibers
39mJRuby: Insights from Six Years in Production