On Feb 10, 12:43 am, Chris Rebert <c...@rebertia.com> wrote: > Considering the GIL, I highly doubt it so. Also, the algorithm is > fundamentally linear -- each result depends on previous results -- so > I don't think you can easily parallelize it (if at all). You'd > probably get greater speedup using memoization. > Even worse than linear, the function is recursive, which as I understand it, is inherently a no-no when looking for code that is parallel-friendly.
If you want multi-core to have some benefit, then your program must have a way for separate parts of the problem to be processed independently. Many matrix processing problems fall into this camp, since the various cells of the matrix can be worked on separately from all others. Prime number searchers break up a problem by having separate processes scan different number ranges independently, or have multiple processes perform rough pass prime filters, who write possible primes to another queue to be more exhaustively checked. This saves the expensive/exhaustive check from being done on every number. Fractal graphics generators (Mandelbrot set plots) can break up the graphics range among different processors, or keep a "queue" of pixels to generate, and each calculator process pulls from the queue until all pixels are computed (some pixels take longer to compute than others). -- Paul -- http://mail.python.org/mailman/listinfo/python-list