Python threading comparison

[Chris Angelico]

On Wed, Jun 23, 2021 at 5:34 AM Dan Stromberg <drsalists at gmail.com> wrote:
>
> I put together a little python runtime comparison, with an embarallel,
> cpu-heavy threading microbenchmark.
>
> It turns out that the performance-oriented Python implementations, Pypy3
> and Nuitka3, are both poor at threading, as is CPython of course.
>
> On the plus side for CPython, adding cpu-heavy threads doesn't cause
> performance to get significantly worse anymore.
>
> The pleasant result is that Micropython threads pretty well!
>
> There's a graph of the performance curves at:
> https://stromberg.dnsalias.org/~strombrg/python-thread-comparison/

The legend's collided with some of the graph itself, making it a bit
hard to read, but if I'm not mistaken, you have CPython and Nuitka
basically identical and worst, and then PyPy much faster but not
benefiting from threads, and uPy as the only one that benefits.

So what that means is that uPy has a completely different
threading/locking model, which is interesting, but all the others are
basically just behaving the same way as each other.

I'd be curious to know how this would be affected if the threads had a
small amount of shared data. Once they get into their main work
(summing a range), they're completely independent, apart from
potentially sharing integer objects in the low range (which will be
completely insignificant in the stats). What if, instead, you create a
single global range object and all the threads iterate over it?

ChrisA