Shared Memory & Parallel Programming with JavaScript
summary
Demonstrates real numbers and trade-offs: naive parallel counts over 200 million iterations slow down due to cache and data races, naive Atomics.add serialises and spikes to ~13 seconds, while per-thread local counters plus one Atomic.add restores speed near the single-thread ~400 ms. Shows SharedArrayBuffer and Atomics for coordinated shared memory and a custom compiler TurboScript that emits asm.js-like code, builds a KD-tree for the Stanford dragon and runs an eight-tile global illumination ray tracer in real time in Three.js.
AI-written summary · about
chapters (14)
- 0:00Shared memory in JavaScript
- 1:13Web Workers memory limits
- 2:24SharedArrayBuffer and Atomics
- 3:59Parallel slower than single-threaded
- 5:31Solving data races with Atomics
- 7:53Naive Atomics performance impact
- 9:05Optimizing parallel counting
- 10:33Ray tracing with shared memory
- 13:35Manual memory serialization challenges
- 15:17TurboScript introduction
- 17:38TurboScript and WebAssembly
- 20:28TurboScript demo
- 22:44TurboScript debugging and future
- 23:30Q&A
related talks
33mParallelism experiments in JavaScript
25mGetting Over Moore's Law: Parallelization Using JavaScript in the Browser
23mParallel JavaScript
41mConcurrency and Parallel Computing in JavaScript
32mMulticore JavaScript: Past, Present and Future
31mJavaScript Compilation Techniques or "Wasn't JavaScript supposed to be slow?"
30mNative Speed on the Web: JavaScript and asm.js
46mHow much performance can you get out of JavaScript?
