I'm glad you brought this up, because I was thinking about it but felt like my relative unfamiliarity with C(++) and a handful of other languages in this "shoot

I'm glad you brought this up, because I was thinking about it but felt like my relative unfamiliarity with C(++) and a handful of other languages in this "shoot-out" made my understanding here flawed (or at least partially naive). I'm also going to piggyback a bit because another thought I had seems related. There's also the issue that among languages like Python, standard libraries (like multiprocessing[0]) make parallelizing code trivial (even with/despite the dreaded global interpreter lock). I rewrote some of the code the author uses and on a smaller number (6710886 instead of 67108864) I'm seeing ~1/3 the time to run compared to his baseline with 4 worker processes (27.469517s vs 1:25.373176). I haven't looked into what might be keeping it from being a full 4x faster, but my hunch is that it's a combination of other things going on in my laptop and the undeniable difference in execution speed in cPython (specifically, cPython3.4). One might make the argument that this is a wildly unfair comparison, but my bigger-picture argument is that a language that abstracts things like parallelization to the point that one can invoke such features in a line or two of added & changed code is probably worth factoring into an analysis, if we're even interested in analyzing languages in this way. If we're going to write C-like code and run it as Python, should we be surprised when it doesn't live up to those expectations? [0]: https://docs.python.org/3.4/library/multiprocessing.html https://docs.python.org/3.4/library/multiprocessing.html