I’m not sure what the author meant by this. Python does support parallelism via multiprocessing (and in experimental versions, via threads in no-GIL builds), e.g. like this. It’s a bit questionable whether it’d help in this particular benchmark, because the overhead of sending the inputs between workers may be comparable to the speedup, but it’s certainly possible, and very common in real tasks.
(I’m not familiar with Ruby, but from some googling it seems the situation is about the same as Python, but there’s not a stdlib implementation and instead you need to use something third-party like the parallel gem.)
The author is referring to the GIL, I’m pretty sure. Both Python and Ruby have it. I guess, they should’ve written “only Clojure supports true multithreading”, but that you’re able to spawn multiple processes is kind of a given (and has quite some disadvantages for certain workloads).
That Python has experimental no-GIL builds is good, but I wouldn’t seriously consider using that until they’ve had it in a stable release and thrown some bug fixes onto it. Well, and even then, there might not be much point in trying to use it, until libraries have adopted it…
I’m not sure what the author meant by this. Python does support parallelism via multiprocessing (and in experimental versions, via threads in no-GIL builds), e.g. like this. It’s a bit questionable whether it’d help in this particular benchmark, because the overhead of sending the inputs between workers may be comparable to the speedup, but it’s certainly possible, and very common in real tasks.
(I’m not familiar with Ruby, but from some googling it seems the situation is about the same as Python, but there’s not a stdlib implementation and instead you need to use something third-party like the
parallel
gem.)The author is referring to the GIL, I’m pretty sure. Both Python and Ruby have it. I guess, they should’ve written “only Clojure supports true multithreading”, but that you’re able to spawn multiple processes is kind of a given (and has quite some disadvantages for certain workloads).
That Python has experimental no-GIL builds is good, but I wouldn’t seriously consider using that until they’ve had it in a stable release and thrown some bug fixes onto it. Well, and even then, there might not be much point in trying to use it, until libraries have adopted it…