[Python-ideas] solving multi-core Python

[Nick Coghlan]

On 26 June 2015 at 00:08, Nick Coghlan <ncoghlan at gmail.com> wrote:
> That does suggest to me a possible "archetypal problem" for the work
> Eric is looking to do here: a 2D canvas with multiple interacting
> circles bouncing around. We'd like each circle to have its own
> computational thread, but still be able to deal with the collision
> physics when they run into each other. We'll assume it's a teaching
> exercise, so "tell the GPU to do it" *isn't* the right answer
> (although it might be an interesting entrant in a zoo of solutions).
> Key performance metric: frames per second

The more I think about it, the more I think this (or at least
something along these lines) makes sense as the archetypal problem to
solve here.

1. It avoids any temptation to consider the problem potentially IO
bound, as the only IO is rendering the computational results to the
screen
2. Scaling across multiple machines clearly isn't relevant, since
we're already bound to a single machine due to the fact we're
rendering to a local display
3. The potential for collisions between objects means it isn't an
embarrassingly parallel problem where the different computational
threads can entirely ignore the existence of the other threads
4. "Frames per second" is a nice simple metric that can be compared
across threading, multiprocessing, PyParallel, subinterpreters, mpi4py
and perhaps even the GPU (which will no doubt thump the others
soundly, but the comparison may still be interesting)
5. It's a problem domain where we know Python isn't currently a
popular choice, and there are valid technical reasons (including this
one) for that lack of adoption
6. It's a problem domain we know folks in the educational community
are interested in seeing Python get better at, as building simple
visual animations is often a good way to introduce programming in
general (just look at the design of Scratch)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia