On 9/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Possibly, but as it stands now interpreters just execute in their own Python thread, so there is no real performance boost. Without the GIL shifting over to per interpreter instead of per process there is going to be the same performance problems as with Python threads. And changing that would be hard since objects can be shared between multiple interpreters.
-Brett
Andre Meyer wrote:
> While I understand the difficulties in removing the GIL and the
> potential negative effect on single-threaded applications I would very
> much encourage discussion to seriously consider removing the GIL (maybe
> optionally) in Py3k. If not, what alternatives would you suggest?
Brett Cannon's sandboxing work (which aims to provide first-class support for
multiple interpreters in the same process for security reasons) also seems
like a potentially fruitful approach to distributing processing to multiple cores:
- use threads to perform blocking I/O in parallel
- use multiple interpreters to perform Python execution in parallel
Possibly, but as it stands now interpreters just execute in their own Python thread, so there is no real performance boost. Without the GIL shifting over to per interpreter instead of per process there is going to be the same performance problems as with Python threads. And changing that would be hard since objects can be shared between multiple interpreters.
-Brett
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
