Step 1: measure! Unless you measure, you can't tell what's costing you time here. It could be rendering the circles. It could be processing the physics. It could be overhead in interprocess communication. Both of the latter appear to be O(N^2), and the communication costs cannot be parallelized. However, it does seem likely the calculations are the significant cost unless you have a ridiculous number of cores and amazing memory bandwidth.
Your calculations look reasonably amenable to use of numpy. This will do the numeric calculations in well-optimized C code. The for-loop in attract is embarrassingly parallel and shouldn't be hard to convert to an array-based form. In addition, since numpy releases the GIL during most array operations, you might find that multi-threading is good enough, and if you do go down that route you could avoid some of the cost of inter-process communication. It might be obvious, but pick a number of workers that does not exceed your available number of cores. There's no value in having the workers fight each other for time on the same cores. multiprocessing.Pool will by default pick a number of workers equal to your number of cores, so you probably don't need to override it. If after all that it's still not fast enough, I suspect you'll need to go to GPU-based solutions. Given the nature of the problem, I'd imagine you could get a good further speed boost out of this route, but you may well need to spend days or weeks getting familiar with these technologies. On Jan 20, 2012 2:24 AM, "Silver" <[email protected]> wrote: > On 1/19/2012 5:33 PM, Silver wrote: > > On 1/19/2012 5:32 PM, Silver wrote: > >> I'm trying to speed up this program as much as possible. Anyone able to > >> help? > >> > >> > > Waugh. Old version... > > Oddly enough, lowering the amount of extra workers in the pool results > in a higher speed? >
