Jure Erznožnik wrote: > On Jun 20, 1:36 am, a...@pythoncraft.com (Aahz) wrote: >> You should put up or shut up -- I've certainly seen multi-core speedup >> with threaded software, so show us your benchmarks! >> -- > > Sorry, no intent to offend anyone here. Flame wars are not my thing. > > I have shown my benchmarks. See first post and click on the link. > That's the reason I started this discussion. > > All I'm saying is that you can get threading benefit, but only if the > threading in question is implemented in C plugin. > I have yet to see pure Python code which does take advantage of > multiple cores. From what I read about GIL, this is simply impossible > by design. > > But I'm not disputing the fact that cPython as a whole can take > advantage of multiple cores. There certainly are built-in objects that > work as they should.
I never used threading together with I/O intensively before, but I heard that I/O operations releases the GIL, and such they're similar to GIL-releasing C extensions which makes it possible to benefit from multicore in I/O bound pure python code. Perhaps we should have more built-in/stdlib operations that can release GIL safely to release GIL by default? And perhaps some builtin/stdlib should receive an optional argument that instruct them to release GIL and by passing this argument, you're making a contract that you wouldn't do certain things that would disturb the builtin/stdlib's operations; the specifics of what operations are prohibited would be noted on their docs. -- http://mail.python.org/mailman/listinfo/python-list
