3 ms·

I'm not clear on the desired result of this project. Is it to make currently-unsafe Python code automatically correct? Or is it to keep the GIL semantics, but m

I'm not clear on the desired result of this project. Is it to make currently-unsafe Python code automatically correct? Or is it to keep the GIL semantics, but make it faster? If it is the former, then I worry. Software transaction memory is hard to get right in languages without explicit and trustworthy annotations for side-effecting code (ie, types) [1]. 1) http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetros... (currently down, but Google has a cached copy)

kingkilr 15y ago
The goal is to remove the GIL from PyPy. RPython (the language our VM is written in) has excellent annotations on things like side-effects.
andrewcooke 15y ago
python doesn't scale well with multiple threads/cores[1]. the high level motivation is to fix that. since the GIL is the main source of the problems, that has to go. [1] the best current solution is to use the multiprocessing package which runs a completely separate python instance on each core, but obviously that doesn't support simple shared memory access (you can do it, but it's not "natural").
masklinn 15y ago
> Is it to make currently-unsafe Python code automatically correct? Or is it to keep the GIL semantics, but make it faster? Neither. It's to improve concurrency in the interpreter (there currently is none whatsoever due to the GIL), so that multithreaded software can scale on multiple cores performing Python bytecode execution. Currently, the GIL means the Python interpreter can only execute Python code in a single OS thread at a time (C extensions such as I/O systems can release the GIL). The result is that, even with a number of (OS) threads spawned in the interpreter, you don't get much parallelism benefits. And even if only one thread performs computation and the rest does I/O, there are churning issues with the GIL (I recommend checking David Beazley's research and presentations on the subject[0]). [0] http://dabeaz.com/blog.html http://dabeaz.com/blog.html section "The GIL"

kingkilr 15y ago

The goal is to remove the GIL from PyPy. RPython (the language our VM is written in) has excellent annotations on things like side-effects.

andrewcooke 15y ago

python doesn't scale well with multiple threads/cores[1]. the high level motivation is to fix that. since the GIL is the main source of the problems, that has to go. [1] the best current solution is to use the multiprocessing package which runs a completely separate python instance on each core, but obviously that doesn't support simple shared memory access (you can do it, but it's not "natural").

masklinn 15y ago

> Is it to make currently-unsafe Python code automatically correct? Or is it to keep the GIL semantics, but make it faster? Neither. It's to improve concurrency in the interpreter (there currently is none whatsoever due to the GIL), so that multithreaded software can scale on multiple cores performing Python bytecode execution. Currently, the GIL means the Python interpreter can only execute Python code in a single OS thread at a time (C extensions such as I/O systems can release the GIL). The result is that, even with a number of (OS) threads spawned in the interpreter, you don't get much parallelism benefits. And even if only one thread performs computation and the rest does I/O, there are churning issues with the GIL (I recommend checking David Beazley's research and presentations on the subject[0]). [0] http://dabeaz.com/blog.html http://dabeaz.com/blog.html section "The GIL"