On 26 June 2015 at 00:08, Nick Coghlan <ncoghlan@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@gmail.com | Brisbane, Australia