I hugely appreciate the whole section that&#x27;s a &quot;rant&quot; on synchronicity.<p>Algorithms should always produce the same results on the same inputs.  There.  I said it.<p>Relaxing constraints on large graph processing or AI systems because A) threads are hard and B) we&#x27;re tossing in random values anyway is a mistake that&#x27;s made research in these areas far too hard to reproduce and reliably quantify, and that in turn makes progress very difficult.<p>We can engineer better than this.  Build random systems with deterministic seeds.  Pass the seeds down in initialization trees if necessary; never refer to a global random source from another thread, and providing a whole system with enough &quot;random&quot;ness for stochastic behaviors AND keeping it deterministic and reproducible is 100% possible.  When going concurrent, build flows and when there&#x27;s a merge, sort results before passing on: determinism AND parallelization <i>are</i> possible.<p>As a personal anecdote, my first forays into ML are covered with rand() calls, and in retrospect, it&#x27;s head-smashingly obvious that this was a Bad Idea.  I spent huge amounts of time re-running the same code, then making a one-character change to a constant or sign somewhere, then re-running it dozens of times again to be sure it had any predictable impact at all.  If I had made it deterministic, it would be obvious immediately, and I could have iterated much faster.  It would also be far easier to farm out a CI&#x2F;lab cluster with different (but consistent) rand seeds to gather meaningful results in bulk.  I could have saved hundreds of hours of my attention (and sanity), even on small projects.<p>Once these things become a bar for minimum viable quality in research, we can start catching, debugging, and improving -- stuff like the &quot;kingmaker scheduler&quot; problem the author describes can be made to vanish.<p>If only we had a video of Ballmer chanting &quot;Determinism! Determinism! Determinism!&quot;...