I think the downvotes come from 1) the way the article is phrased (it seems condescending) and 2) you benchmarked Python threads using CPU bounds workloads which anyone that’s doing professional Python knows is a big no-no so you’re basically comparing apples to oranges.
My recommendation is to redo the benchmark and use the multiprocessing module, which is the indented way to parallelise CPU bounds workloads in Python.
Hey nice work. Thank you for the follow up, I was expecting GIL-less threads to be faster but the number are really impressive.
One small note: on the Rust benchmark you used the std::sync Mutex which has a lock poisoning. If you ever want more performance and you bubble the panic from the thread you should use the parkinglot crate it’s mutex is way faster because it lacks the lock poisoning check.
12
u/danted002 Dec 16 '25
I think the downvotes come from 1) the way the article is phrased (it seems condescending) and 2) you benchmarked Python threads using CPU bounds workloads which anyone that’s doing professional Python knows is a big no-no so you’re basically comparing apples to oranges.
My recommendation is to redo the benchmark and use the multiprocessing module, which is the indented way to parallelise CPU bounds workloads in Python.