Presently, python has the GIL - Global Interpreter Lock. It means any given instance of Python can only execute a single thread at a time, which is a massive concurrency penalty but made the...
Presently, python has the GIL - Global Interpreter Lock. It means any given instance of Python can only execute a single thread at a time, which is a massive concurrency penalty but made the interpreter much easier to write and potentially makes it easier for developers to avoid certain concurrency bugs.
Removing GIL won't make a single instance able to use multiple cores - that still requires multi process programming. However, Python currently requires multi process programming techniques to even get full performance from a single core, since GIL meant only a single Python instruction could be going at a time, even if it's one that would cause a wait state. Something like C++ can have several threads going in parallel - while it's still only one instruction at a time executing, if one stalls, it will automatically switch to another ready thread.
Edit: Well per other comments, apparently it's more controversial than that as some debate about whether it actually improved anything when tried in the past etc. etc. little complicated for me...
Sounds like a positive thing to me, then, to help keep python modern. Edit: Well per other comments, apparently it's more controversial than that as some debate about whether it actually improved anything when tried in the past etc. etc. little complicated for me but the combined responses to my question have all been helpful anyway.
Like others have said, it's not 100% upside. Python has a lot of language structures written with this bottleneck in mind. While only a single Python instruction/thread can run at a time, a single...
Like others have said, it's not 100% upside. Python has a lot of language structures written with this bottleneck in mind. While only a single Python instruction/thread can run at a time, a single Python instruction can map to a number of C calls or syscalls, even potentially multiple threads. So you can work around it by structuring your data and program with this in mind - one joke about Python is that the best way to get performance out if it is to spend as little time as possible actually doing Python.
It would, however, potentially make it much easier to make performant code. Perfectly tuned pythonic code would be unlikely to benefit as it's not impacted, but you'd no longer have to bend over backwards to work around the language to get something that is 95% as performant, where now using more traditional language constructs can literally be orders of magnitude slower. It won't get around that entirely (there's a lot of areas in which for example loops will absolutely kill you in Python), but there's a strong argument to make that the programmer time lost to crafting perfect Python code is enough of a cost that we're better taking a small hit in the perfect case for the massive gains in the common cases.
In the reference version of the Python interpreter (cpython) there are lots of optimisations which make it work faster and take less memory, but which also rely on the fact that only one thread...
In the reference version of the Python interpreter (cpython) there are lots of optimisations which make it work faster and take less memory, but which also rely on the fact that only one thread can use the interpreter at a time. Whenever a thread is using the interpreter, all the other threads are locked out of it. They have to wait their turn. That's the global interpreter lock, GIL. This sometimes constrains what you can accomplish with Python, in terms of making use of multiple processor cores.
For most things the GIL is no trouble at all. For example if you are doing a long computation in NumPy you can still use other threads while the computation is running. NumPy doesn't need to use the interpreter while it's computing a fourier transform.
There has been debate for many years about whether to try and revise cpython to remove the GIL. So far, every time someone has made a version of cpython without the GIL it has actually been slower for most common tasks, since it can't use all the same optimisations. The core developers have thus far chosen not to spend much time on removing the GIL, since it would make the interpreter much more complicated and it wouldn't help most workflows. Their time and resources are limited, and they have chosen to spend them on other improvements to Python.
Some workflows, particularly in machine learning, actually would see big speed improvements with no GIL. Training a neutral network, for example, benefits from lots of threads all modifying the same data structure. Many Python frameworks for this delegate to subprocesses written in other languages which can make full use of the available processor cores. If all that could be done within the same Python process that might make things simpler. Another place it might help is with video games, where you want to make full use of everything your computer has.
Facebook has more money than they know what to do with. If they are willing to devote the resources needed to make a version of cpython which is just as fast but without the GIL, that could make some tasks in Python way quicker.
This is the proposal they're talking about. It's basically to add an option to CPython (which is the most common Python implementation) to be optionally built to natively enable concurrency,...
This is the proposal they're talking about. It's basically to add an option to CPython (which is the most common Python implementation) to be optionally built to natively enable concurrency, instead of having to deal with one of the complicated workarounds.
For the layman what does this mean? Any implications to the wider world or is this pretty much just a straight-up coding practice thing?
Presently, python has the GIL - Global Interpreter Lock. It means any given instance of Python can only execute a single thread at a time, which is a massive concurrency penalty but made the interpreter much easier to write and potentially makes it easier for developers to avoid certain concurrency bugs.
Removing GIL won't make a single instance able to use multiple cores - that still requires multi process programming. However, Python currently requires multi process programming techniques to even get full performance from a single core, since GIL meant only a single Python instruction could be going at a time, even if it's one that would cause a wait state. Something like C++ can have several threads going in parallel - while it's still only one instruction at a time executing, if one stalls, it will automatically switch to another ready thread.
Sounds like a positive thing to me, then, to help keep python modern.Edit: Well per other comments, apparently it's more controversial than that as some debate about whether it actually improved anything when tried in the past etc. etc. little complicated for me but the combined responses to my question have all been helpful anyway.Thank you and everyone else who replied.
Like others have said, it's not 100% upside. Python has a lot of language structures written with this bottleneck in mind. While only a single Python instruction/thread can run at a time, a single Python instruction can map to a number of C calls or syscalls, even potentially multiple threads. So you can work around it by structuring your data and program with this in mind - one joke about Python is that the best way to get performance out if it is to spend as little time as possible actually doing Python.
It would, however, potentially make it much easier to make performant code. Perfectly tuned pythonic code would be unlikely to benefit as it's not impacted, but you'd no longer have to bend over backwards to work around the language to get something that is 95% as performant, where now using more traditional language constructs can literally be orders of magnitude slower. It won't get around that entirely (there's a lot of areas in which for example loops will absolutely kill you in Python), but there's a strong argument to make that the programmer time lost to crafting perfect Python code is enough of a cost that we're better taking a small hit in the perfect case for the massive gains in the common cases.
In the reference version of the Python interpreter (cpython) there are lots of optimisations which make it work faster and take less memory, but which also rely on the fact that only one thread can use the interpreter at a time. Whenever a thread is using the interpreter, all the other threads are locked out of it. They have to wait their turn. That's the global interpreter lock, GIL. This sometimes constrains what you can accomplish with Python, in terms of making use of multiple processor cores.
For most things the GIL is no trouble at all. For example if you are doing a long computation in NumPy you can still use other threads while the computation is running. NumPy doesn't need to use the interpreter while it's computing a fourier transform.
There has been debate for many years about whether to try and revise cpython to remove the GIL. So far, every time someone has made a version of cpython without the GIL it has actually been slower for most common tasks, since it can't use all the same optimisations. The core developers have thus far chosen not to spend much time on removing the GIL, since it would make the interpreter much more complicated and it wouldn't help most workflows. Their time and resources are limited, and they have chosen to spend them on other improvements to Python.
Some workflows, particularly in machine learning, actually would see big speed improvements with no GIL. Training a neutral network, for example, benefits from lots of threads all modifying the same data structure. Many Python frameworks for this delegate to subprocesses written in other languages which can make full use of the available processor cores. If all that could be done within the same Python process that might make things simpler. Another place it might help is with video games, where you want to make full use of everything your computer has.
Facebook has more money than they know what to do with. If they are willing to devote the resources needed to make a version of cpython which is just as fast but without the GIL, that could make some tasks in Python way quicker.
This is the proposal they're talking about. It's basically to add an option to CPython (which is the most common Python implementation) to be optionally built to natively enable concurrency, instead of having to deal with one of the complicated workarounds.