On Fri, Jun 19, 2009 at 6:10 PM, Jure Erznožnik<jure.erznoz...@gmail.com> wrote: > On Jun 19, 11:59 pm, Jesse Noller <jnol...@gmail.com> wrote: >> On Fri, Jun 19, 2009 at 12:50 PM, OdarR<olivier.da...@gmail.com> wrote: >> > On 19 juin, 16:16, Martin von Loewis <martin.vonloe...@hpi.uni-: >> >> If you know that your (C) code is thread safe on its own, you can >> >> release the GIL around long-running algorithms, thus using as many >> >> CPUs as you have available, in a single process. >> >> > what do you mean ? >> >> > Cpython can't benefit from multi-core without multiple processes. >> >> > Olivier >> >> Sorry, you're incorrect. I/O Bound threads do in fact, take advantage >> of multiple cores. > > Incorrect. They take advantage of OS threading support where another > thread can run while one is blocked for I/O. > That is not equal to running on multiple cores (though it actually > does do that, just that cores are all not well utilized - sum(x) < > 100% of one core). > You wil get better performance running on single core because of the > way GIL is implemented in all cases.
No. That's simply incorrect. I (and others) have seen significant increases in threaded, I/O bound code using multiple cores. It's not perfect, but it is faster. -- http://mail.python.org/mailman/listinfo/python-list
