No GIL. It would mean being able to use (pure) Python for parallellizable tasks without having to launch multiple processes of it and set up IPC for synchronizing the task execution.
If Python were too slow for me (and a JIT would help), I could try to solve that by using a more powerful server or adding more servers.
@bronger I think saying "this survey is pointless" is a bit presumptuous without knowing my motivation behind the survey and why I structured it this way.
You not knowing the details is on purpose for what I'm interested in knowing about people's perception of both topics.
@gpshead @brettcannon How many modules are affected? Do modules have to be maintained in two variants? How difficult is the migration? Will the GIL be off by build settings or interpreter arguments?
Think of how difficult is was to estimate the costs of Python 3000! Every survey has inaccuracies but this is too much.
If you just want to know whether vertical or horizontal scaling is more important, ask that instead.
@brettcannon I voted for JIT.
I believe it would bring the clearer and most immediate benefits for all python workloads already out there.
@brettcannon @itsthejoker maybe. but I run a project that has a plugin system and frankly getting IPC wrapped transparently so (often inexperienced) plugin authors have it as easy as possible sounds like the opposite of a good time π¬
Plus I'm currently still stuck on a minimum supported python version of 3.7 due to this being a thing that users self-install in their own environment.
Admittedly that also means years before -GIL or +JIT would help me anyhow π
@brettcannon a JIT would make life immediately better. no GIL would be...how would that even work, would modules have to declare "from __future__ import nogil" to guarantee that they have used threading.Lock() every time they pop from a dictionary? common people VOTE FOR JIT
@brettcannon Not quite sure where I lean on this.
On the one hand - no GIL would be great. It really hurts to run single-core on multi-core machines.
On the other hand - I'm pretty sure we'll have to rewrite most existing libraries to be properly thread-safe, and I don't think anyone wants that. I mean - how do you even go about it? Add "no GIL" as a specifier for packages?
JIT is tricky as well. Can `inspect` keep working as it is? Will we have to give things up? How do we manage that?
@tmr232 https://peps.python.org/pep-0703/ for the no-GIL details, but yes, packages would need "GIL" and "no GIL" wheels.
As for the JIT, why do you think 'inspect' would stop working when the source code had to be there to JIT to begin with?
CPythonβs global interpreter lock (βGILβ) prevents multiple threads from executing Python code at the same time. The GIL is an obstacle to using multi-core CPUs from Python efficiently. This PEP proposes adding a build configuration (--disable-gil) to...
@brettcannon But by trying we will learn a lot of things that will benefit Python and the community in other ways? Such as for the initiative to make Python x times faster.
So, there is much to gain just by trying - which is also the only way to find out if it can be done π€
YJIT, a just-in-time (JIT) implementation on top of CRuby built at Shopify, is now production-ready and delivering major improvements to performance and speed. Maxime shares the updates that have been made in this newest version of YJIT, and future plans for further optimization.
I assume you meant 684. But if you have multiple interpreters, how do they share objects without a (shared) GIL?
@brettcannon
Please refer to my test case here: https://bpa.st/47SDC
Multiple interpreters doesn't solve my problem unless there is also a no-GIL communication channel between them.
Usage is explained in pep554, TLDR still has GIL limitations, but wants to do the following:
* increase exposure of the existing feature, which helps improve
the code health of the entire CPython runtime
* expose the (mostly) isolated execution of interpreters
* preparation for per-interpreter GIL
* encourage experimentation
Overall, this could be interesting and I can imagine some libraries written on top of it, but doesnt solve the problem significantly enough for me
@brettcannon jit is my vote. I believe it'd get greater flexibility in experimentation, jit implementation, and production use. We could see different jits for different processing use cases, written in C++, rust, java, etc., enabled in some pieces of the software and not others, etc.
If there's a good all-around jit then it could get used as a standard in sub-interpreters, and you'd still be able to use a java-implemented jit for jython-compatible code, perhaps.
@bluegreenzeros If you or your company would like to fund such an effort to have both, I am sure an arrangement can be made with the PSF to fund such an endeavour π
@brettcannon i vote #NoGIL. I do machine learning research, often prototyping code on my local computer (with a quite competent multicore CPU), and i think threads could give me quite some improvements there. Not bringing out the big guns like dask every time might improve latency in development iterations, for example. On the other hand, i think I am badly informed about the implications of a #JIT compiler.
Would love an episode of @pythonbytes discussing the topic.
Brett Cannon
Matt Welke
Florian Apolloner
Torsten Bronger
Gregory P. Smith (he/him) 
π²π¦ 
Rob van der Linde
Robert Grimm
Sekou Diao
Joe Kaufeld
Gina HΓ€uΓge
mike bayer 
Jonathan LaCour
David Beazley
Bert JW Regeer π³οΈβπ
Tin TvrtkoviΔ
Tamir Bahar
Jan Katins
Thomas Svensson π
jacobian
ivoflipse
Alistair Buxton
BlueGreenZeros
Andrew Diederich
elhult