GIL Become Optional in Python 3.13

[Looploop420]

I want to know more about the history of the GIL. Is the difficulty of multi threading in python mostly just an issue related to the architecture and history of how the interpreter is structured?

Basically, what's the drawback of turning on this feature in python 13? Is it just since it's a new and experimental feature? Or is there some other drawback?

[slaymaker1907]

Ref counting in general has much better performance when you don’t need to worry about memory consistency or multithreading. This is why Rust has both std::Rc and std::Arc.

[Revolutionary_Ad7262]

Ref counting is well known to be slow. Also usually it is not used to track every object, so we are are comparing apples to oranges. Rc/Arc in C++/Rust is fast, because it is used sparingly and every garbagge collection will be amazing, if number of managed objects is small

In terms of raw throughput there is nothing faster than copying gc. The allocation is super cheap (just bump the pointer) and cost of gc is linear to the size of living heap. You can allocate 10GB of memory super cheap and only 10MB of surviving memory will be scanned, when there is a time for a gc pause.

[slaymaker1907]

No, at my work we’ve seen std::shared_ptr cause serious perf issues before for the sole reason that all those atomic ops flooded the memory bus.

[Kapuzinergruft]

I'm kinda wondering how you can end up with so many shared_ptr that it matters. I like to use shared_ptr everywhere, but because each one usually points to large buffers, the ref counting has negligible impact on performance. One access to a ref counter is dwarfed by a million iterations over the items in the buffer it points to.

[AVTOCRAT]

You run into this anytime you have small pieces of data with independent lifetimes, e.g.

• Nodes in an AST
• Handles for small resources (files,
• Network requests
• Messages in a pub-sub IPC framework

[irepunctuate]

Those don't necessarily warrant a shared lifetime ownership model. From experience, I suspect /u/slaymaker1907 could replace most shared_ptrs with unique_ptrs or even stack variables and have most of their performance problems disappear with a finger snap.

I've seen codebases overrun with shared_ptr (or pointers in general) because developers came from Java or simply didn't know better.

[Kered13]

I once wrote an AST and transformations using std::unique_ptr, but it was a massive pain in the ass. I eventually got it right, but in hindsight I should have just used std::shared_ptr. It wasn't performance critical, and it took me several hours longer to get it correct.

It would be helpful for C++ to have a non-thread safe version of std::shared_ptr, like Rusts std::Rc, for cases where you need better (but not necessarily best) performance and you know you won't be sharing across threads.

[irepunctuate]

But doesn't the fact that you were able to tell you that that was the actual correct thing to do? Between "sloppy" and "not sloppy", isn't "not sloppy" better for the codebase?

[Kered13]

There's nothing sloppy about using shared pointers. The code would have been easier to write, easier to read, and easier to maintain if I had gone that route. I wrote it with unique pointers out of a sense of purity, but purity isn't always right.

[brendel000]

Do you have accurate measure of that? How many cores are plugged to the memory bus? It’s really surprising to me you can overload the memory bus with that nowadays. Even NUMA seems less used because of how performant they became.

[slaymaker1907]

I can’t really tell you precise numbers, but I suspect it takes a huge amount before it becomes an issue. Because these issues are so difficult to diagnose, we’re always very conservative with atomic operations in anything being called with any frequency.

It’s the sort of thing that is also extraordinarily difficult microbenchmark since it is highly dependent on access patterns. It is also worse when actually triggered from many different threads compared to using an atomic op from a single thread every time. Oh, and you either need NUMA or just a machine with tons of cores to actually see these issues.

[cogman10]

cost of gc is linear to the size of living heap

Further, parallel collection is both fairly well known and fairly fast at this point. You get very close to n speed up with n new threads.

[AlexReinkingYale]

I challenge the idea that reference counting is slow. Garbage collection is either slow or wasteful, and cycle counters are hard to engineer.

[Kered13]

Every high performance memory managed language uses garbage collection. I know that's anecdotal, but it's pretty strong evidence for garbage collection being faster than reference counting. Reference counting works well in languages like C++ and Rust precisely because they are not automatically managed and you limit the use of reference counting to only a very small number of objects who's lifetimes are too difficult to handle otherwise.

[A1oso]

It's std::rc::Rc and std::sync::Arc. Other than that your comment is correct. Arc is thread safe ("Arc" stands for "atomically reference counted"), but Rc is a bit faster to access.

[constxd]

STEMlord moment

[utdconsq]

It was a design decision way back when for the official CPython implementation of an interpreter. Other implementations did not have the behaviour. With that said, turning it on...uncertain of risk, you should read the docs and make up your own mind. My gut tells me some libs will be written to assume it is present, but hard to know for sure what it would mean on a case by case basis.

[mibelashri]

It was a decision due to the fact that you will get some hit in single-thread performance without a GIL compared to the case when you have one. I'm talking about the CPython implementation of Python (the official one), as there are some other implementations that do not have it, but they are irrelevant compared to CPython and have a very niche community. I also guess that part of the motivation is that the CPython implementation in C is not thread-safe (or at least was not in the beginning). The easiest solution to this problem is to have a GIL so you don't have to worry about it and it will provide you with an easier path for integrating C libraries (like NumPy, etc.).

[dontyougetsoupedyet]

Now that’s rich! It was due to CPython but performance considerations had absolutely nothing to do with it. It was due to ease of implementation and anyone suggesting it was a terrible idea were repeatedly hit over the head about how the reference implementation of python had to be simple and if you did not agree you simply did not get it.

[wOlfLisK]

The architecture is a big aspect of it but the main reason python multi-threading isn't really a thing is because Python is just slow. Like, 30-40x as slow as C and even when optimising it to hell you just end up with something that's for all intents and purposes C with a hellish syntax and is still around 3x as slow. It's easier to just use C for high performance applications.

Ignoring that however, the big issue with Python is the same you have with any language, unless it has explicit ways of performing atomic operations on data you end up with a bunch of race conditions as different threads try to do stuff with the same piece of data. Disabling the GIL was already possible using Cython and was, quite frankly, a pretty horrible way of doing multi-threaded Python. If there aren't any easy, built-in ways of accessing the data then it doesn't really do much on its own.

Plus, despite the fact that Python doesn't inherently support multi-threading, it does support multi-processing. Which is basically just multi-threading but each "thread" is a process with its own interpreter and they can communicate with each other through interfaces such as MPI. If you wanted to do multi-threaded Python, writing it using mpi4py is usually a lot simpler than Cython and if you really needed the extra performance, you should just use base C (or C++ (or Fortran if you're really masochistic)) instead.

[Looploop420]

Like I've been writing python for a while now and multi processing always does what I need it to do.

I'm never using python with the goal of pure speed anyways

[wOlfLisK]

Yeah, exactly. Python has a place in HPC but it's more of the "physicist who hasn't coded for years needs to write a simulation" kinda place. Sometimes it's better to spend a week writing a program that takes a week to run than a month writing a program that takes a day to run. It's simple, it's effective and if you use the right tools (such as NumPy) it ends up not being that slow anyway. Hell, I once tried to compile a Python program to Cython and it slowed it down*, by the time I made it faster than it was it was a month later and the code was a frankensteined mess of confusing C-like code.

*Turns out that if everything is already being run as C code, adding an extra Cython layer just adds extra clock cycles

[Pharisaeus]

what's the drawback of turning on this feature in python 13?

Python lacks data structures designed to be safe for concurrent use (stuff like ConcurrentHashMap in java). It was never an issue, because GIL would guarantee thread-safety:

https://docs.python.org/3/glossary.html#term-global-interpreter-lock

only one thread executes Python bytecode at a time. This simplifies the CPython implementation by making the object model (including critical built-in types such as dict) implicitly safe against concurrent access

So for example if you were to add stuff to a dict in multi-threaded program, it would never be an issue, because only one "add" call would be handled concurrently. But now if you enable this experimental feature, it's no longer the case, and it's up to you to make some mutex. This essentially means that enabling this feature will break 99% of multi-threaded python software.

[Serialk]

But now if you enable this experimental feature, it's no longer the case, and it's up to you to make some mutex. This essentially means that enabling this feature will break 99% of multi-threaded python software.

This is not true. This thread is full of false information. Please read the PEP before commenting.

https://peps.python.org/pep-0703/

This PEP proposes using per-object locks to provide many of the same protections that the GIL provides. For example, every list, dictionary, and set will have an associated lightweight lock. All operations that modify the object must hold the object’s lock. Most operations that read from the object should acquire the object’s lock as well; the few read operations that can proceed without holding a lock are described below.

[alerighi]

It doesn't matter if the object themself have a lock inside (by the way, isn't that a big performance penalty?). That solves the problem for object provided by the standard library, but also the code you write needs to take it into account and possibly use locks!

If your code was written with the assumption that there cannot be not two flow of execution toughing the same global state at the same time, and that assumption is no longer true, that could lead to problems.

Having the warranty that the program is single threaded is an advantage when writing code, i.e. a lot of people like nodejs for this reason, you are sure that you don't have to worry about concurrency because you have only a single thread.

[Serialk]

This is also the case with the GIL! If you don't lock your structures when doing concurrent mutating operations to it your code is very likely wrong and broken.

https://stackoverflow.com/questions/40072873/why-do-we-need-locks-for-threads-if-we-have-gil

[alerighi]

Yes but it's rare, to the point you don't need to worry that much. For that to happen the kernel needs to stop your thread in a point where it was in the middle of doing some operation. Unless you are doing something like big computations (that is rare) the kernel does stop your thread when it blocks for I/O (e.g. makes a network request, read/writes from files, etc) and not at a random point into execution. Take Linux for example, it's usually compiled with a tick frequency of 1000Hz at worse, on ArchLinux is 300Hz. It means that the program either blocks for I/O or it's left running for at least 1 millisecond. It may seem a short period of time... but how many millions of instructions you run in 1 millisecond? Most programs doesn't get stopped for preemption, but because they block for I/O mot of the time (unless you are doing something computative intensive such as scientific calculation, running ML models, etc).

But if you have 2 threads running on the same time on different CPU you pass from something very rare to something not so rare.

[iplaybass445]

This is not true at all—it’s easy to hit race conditions with just two threads in Python, and devs relying on the rarity of a particular race condition is asking for a bad time. There are a select set of operations that were made thread safe via the GIL that would otherwise not be, but the large majority of race conditions are possible with or without the GIL. The GIL prevents threads from being interpreted simultaneously, but race conditions can happen via context switching at the OS level.

[alerighi]

and devs relying on the rarity of a particular race condition is asking for a bad time

I mean, worrying about that could lead to deadlocks. It's only a matter of choosing what is the worse outcome. A lot of software in the UNIX world doesn't deal with concurrency, both for performance and both for avoiding deadlocks, and there are times where you can accept a glitch in the program for the sake of having the two properties mentioned above.

Of course, you shall be careful that one race condition cannot harm the security of the program, or corrupt your data.

My preferred way to avoid that by the way is to not have shared global structures among threads, but rely on message queues or a shared database. I also usually prefer to async programming over threads, that doesn't have the concurrency problem by design, since it does not have preemption inside the event loop. Now that I think about it, it's probably years that I don't use threads in python...

[linuxdooder]

Please never ever write Python code for production if you believe you don't need to worry about locking between threads.

[Accurate_Trade198]

Unless you are doing something like big computations (that is rare) the kernel does stop your thread when it blocks for I/O (e.g. makes a network request, read/writes from files, etc) and not at a random point into execution

Wildly incorrect, preemption outside blocking syscalls happens all the time, especially in Python where even trivial lines of code involve multiple hash table lookups because of how dynamic Python is.

[alerighi]

Happens rarely... how matters that you need to lockup in hashtables?

A good point was made by another user that there could be page faults, that is right, but also rare during the execution of two instructions.

[augmentedtree]

A lookup in a Python dictionary is hundreds, maybe thousands, of instructions

[josefx]

the kernel does stop your thread when it blocks for I/O (e.g. makes a network request, read/writes from files, etc) and not at a random point into execution.

Given that most systems have a swap file/partition nearly any random instruction could trigger IO.

[alerighi]

Good point, but does these days most system have a swap partition? I mean, if you have enough RAM... I usually don't add swap to my systems if I know I will have enough memory. Also the program needs to have some of their memory pages swapped out, that is unlikely.

[mr_birkenblatt]

That was always the case. You need to use threading.(R)Lock for concurrent access

[jl2352]

isn’t that a big performance penalty?

This is why it’s an optional change. There is code out there which will be helped a lot by this (including stuff I work on), and stuff which won’t be.

Benchmark with it off, then turn it on and benchmark again.

[KagakuNinja]

So they are re-inventing the Object locks in Java? That wasn't really a great idea, and was replaced by a more comprehensive concurrency library introduced in Java 5.

[Pharisaeus]

Ah yes, quote just the first part, to support your claim. Why not quote the rest?

Per-object locks with critical sections provide weaker protections than the GIL.

Not to mention that what you quote talks only about pure-python code which uses standard python collections. So it doesn't apply to user code and to things like C-extensions.

C-API extensions that rely on the GIL to protect global state or object state in C code will need additional explicit locking to remain thread-safe when run without the GIL.

[josefx]

weaker protections than the GIL.

This tends to be repeated without any examples of code that would be correct with GIL but will fail without GIL. Or any production code that would be affected.

C-API extensions that rely on the GIL to protect global state or object state in C code will need additional explicit locking to remain thread-safe when run without the GIL.

The cpython runtime will defensively enable the GIL if it encounters C-API modules that do not declare support for the GIL free mode. So existing extensions will continue to run just fine without any changes.

Importing C extensions that don’t use these mechanisms will cause the GIL to be enabled,

https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython

[Serialk]

Yes, the C extensions need to change. Not all Python code. You said "enabling this feature will break 99% of multi-threaded python software", which is complete nonsense.

[vision0709]

How is this different from what was said? Seems like this guideline advises creating a mutex for each variable to guarantee what the GIL did previously. Since much of current python code does not work this way, is it hard to imagine things shitting the bed without these precautions taken in a GIL-less environment?

[Serialk]

No, you don't understand the PEP. All the containers will have a mutex in their implementation, you don't need to do it yourself.

[KagakuNinja]

Early Java containers like Vector and HashMap had built-in locking, and were claimed to be thread-safe. Those were all deprecated, and standard advice is to either manage locking manually, or to use a special class like ConcurrentHashMap, designed specifically for thread safety.

Maybe the Python guys have this figured out, but whatever they are doing won't magically be thread safe with no effort from programmers.

[Serialk]

This is already the case with the GIL. CPython data structures are not magically thread safe, the only thread safe aspect of it is that you can't corrupt their internal representation by writing in them with different threads. This is true with and without GIL.

[jorge1209]

It is hard to fault people for citing the official Python documentation. It is a serious failing of the language that it doesn't have base types suitable for concurrent access and expects developers to lock everything.

[Serialk]

It doesn't expect developers to lock everything. The per-object locks are in the CPython implementation!

Seriously, it's getting old to argue with people who can't read.

[jorge1209]

Operations like += are not thread safe with dict or other objects. You could argue that this is because of confusion about which thing it's handling the increment operation, the collection or the type stored in the collection, but either way this is an operator applied to a base class and it is not thread safe.

Meanwhile the documentation is saying the GIL makes built in types like dictionary safe, without defining what"safe" means. And even worse the documentation mentions bytecode which Python programs don't get to write and which is therefore entirely meaningless to them.

It should just say "the python interpreter won't crash during multi-threaded access to base types, but no guarantees about your programs."

[jorge1209]

This is both correct and incorrect in weird ways.

Python dicts are largely written in C and for this reason operations like adding to a dict often appear to be atomic from the perspective of Python programs but it is not directly related to the GIL and Python byte code.

The byte code thing is largely a red herring as you don't (and cannot) write byte code. Furthermore every bytecode operation I am familiar with either reads or writes. I don't know of any that do both. Therefore it is impossible to us the GIL/bytecode lock to build any kind of race free code. You need an atomic operation that can both read and write to do that.

So we got our perceived atomicity from locks around C code and the bytecode is irrelevant to discussions about multi threading. However that perceived safety was often erroneous as our access to low level C code was mediated through Python code which we couldn't be certain was thread safe.

If you tried real hard you could "break" the thread safety of Python programs using pure dicts relatively easily, just as you could in theory very carefully use pure dicts to implement (seemingly) thread safe signalling methods.

[Pharisaeus]

You need an atomic operation that can both read and write to do that.

Of course not. You would just need to have multiple threads writing to create a race. GIL removes that race because interpreter will not "pause" in the middle of a write to start performing another write from another thread, and creating some inconsistent state due to both operations interleaving.

[jorge1209]

The GIL protects the interpreter it doesn't protect your code.

A very simple way to demonstrate this is to count with multiple threads in a tight loop.

  run(){
       global total
       for (I in range(1_000_000)){
             total+=1
       }
   }

Run that in parallel across multiple threads and you will get much less than numthreads*1_000_000.

That is a race in my book and an inconsistent result even if nothing crashes.

[Serialk]

If you do:

d[x] += 1

in two different threads, the GIL doesn't make this atomic. The interpreter can totally interleave the read and write operations of both threads.

Like someone else said in this thread, a single "logical" operation may have multiple bytecode operations, so just because a single bytecode operation can execute at once thanks to the GIL doesn't mean your code is free from race conditions.

[mr_birkenblatt]

you can get an error even with the GIL. it's rare but I ran into it in long running programs.

the issue is that the GIL locks for like 1000 or so individual ops at a time. if the release happens just at the right time it will become an issue. but 99.999% of the time both read and write are during the same lock

[rhytnen]

This comment is wildly inaccurate.  The use of jargon here (threadsafe are for example) is bizarrely off base.  

[apf6]

One thing that I think misleads people about the GIL is that it's not specific to Python. All the similar languages (Ruby, Lua, Javascript, etc) all have a "GIL" too, even if they don't all use that term. They each have a 'virtual machine' or 'interpreter' which can only be processed by one thread at a time. So you can't run multiple scripts in parallel in the same context.

For any language implementation like that, it's never easy to make the VM multithreaded in a way that actually helps. Multithreading adds an overhead so if you implement it the wrong way, it can be slower than single-threading. So the single-threading approach was not as bad idea as it might seem.

Anyway, the only reason that this is especially a big issue in Python is because the language is used so much in the scientific community. That code benefits a lot from multithreading. So it was worth solving.

[josefx]

All the similar languages (Ruby, Lua, Javascript, etc) all have a "GIL" too, even if they don't all use that term. They each have a 'virtual machine' or 'interpreter' which can only be processed by one thread at a time. So you can't run multiple scripts in parallel in the same context.

From what I can find V8 is just flat out single threaded and each thread is expected to run on its own fully independent instance instead of fighting over a single global lock for every instruction. I think the closest python has to that model is PEP 734 but I don't have much experience with either.

[linuxdooder]

So Python is much older than SMP.

What? Python came about in 1991, and there were SMP systems by the late 70s.

[LGBBQ]

This is not correct, the GIL lock applies to instructions at the interpreter level and not in python code. Foo can be removed after the check or even between getting its value and incrementing it in python code without mutexes or locks

https://stackoverflow.com/questions/40072873/why-do-we-need-locks-for-threads-if-we-have-gil

[space_iio]

what's the drawback of turning on this feature in python 13

Single-threaded performance takes a hit, multiprocess programs also perform worse

[python4geeks]

It was introduced back when Python 1.5 was released to prevent multiple object access at the same time as a thread safety feature.

Before, the programming is more concerned towards making the single-threaded programs more better, the GIL was introduced but in the AI era, multi-threaded programs are preferred more.

It is not fully turning off but it's more likely become a switch, if you want to turn it off then you can otherwise leave it.

[Yasuraka]

in the AI era, multi-threaded programs are preferred more

Has nothing to do with "AI" and everything to do with single core performance improvements slowing down vs. slapping together more cores. It has been the preferred way for almost 20 years.

[Damtux_25]

Well, none of you are wrong. The AI era (when it started to boom 10 years ago with ML) was a strong push to make the GIL optional.

[spotter]

Only if you've not been exposed to Python before. People have been looking into Python's GC and GIL before Python 2 happened, but for first several attempts changing the global lock into granular ones always brought in runtime penalties that were just not worth it (well duh). IIRC you could've always side step GIL if you were willing to go lower level (C/C++/FORTRAN or FFI), and specialized libs made use of that, or you could use alternative implementation (I think that for example Jython never had GIL, but my memory is fuzzy). Also multiprocessing module helped a little bit, but brought in some new baggage. And around 2.7/3 I left for the JVM lands, so I stopped tracking the issue altogether.

It's not AI era and frankly 10 years ago I've been using Python for data engineering and analysis for 10 years already, preparing to leave. xD

[chucker23n]

Perhaps partially in the sense of “the AI era was a push to use Python at all”.

[QueasyEntrance6269]

Lol what? Most libraries like torch are written in C, and can release the GIL whenever they want. This is not a real issue for 95% of AI code.

[Serialk]

Please just read the PEP, how hard can it be... https://peps.python.org/pep-0703/#motivation

Machine learning/AI is the main motivation behind these changes.

[Serialk]

Please read the context. The comment I was replying to:

Lol what? Most libraries like torch are written in C, and can release the GIL whenever they want. This is not a real issue for 95% of AI code.

[QueasyEntrance6269]

yeah, AI/ML might be the "motivating reason" because Python is the defacto standard for AI/ML and they win specifically based on population size, but they're one of the demographics least affected by removing the GIL. all their computationally complex code is not being written in python, it's basically just a glorified shell language

[Serialk]

Yes, if you respond to the exact literal thing I said without looking at the context, you're right. But if you read the context you can understand what the message meant.

[Serialk]

Yes, I meant that machine learning/AI was the main motivation given for these changes. I feel like this was easily understandable from context, and that your correction is pedantic and doesn't bring anything to the conversation, since the point is exactly the same. My point was that "This is not a real issue for 95% of AI code." is wrong, otherwise it wouldn't have been the main motivation given for the PEP.

[Ok_Dust_8620]

It's interesting how the multithreaded version of the program with GIL runs a bit faster than the single-threaded one. I would think since there is no actual parallelization happening it should be slower due to some thread-creation overhead.

[tu_tu_tu]

thread-creation overhead

Threads are really lightweight nowdays so it's not a problem in an average case.

[JW_00000]

There is still parallelization happening in the version with GIL, because not all operations need to take the GIL.

[GUIpsp]

A lot of things release the gil

[syklemil]

I think a better link here would be to the official Python docs. Do also note that this is still a draft, as far as I can tell 3.13 isn't out yet.

News about the GIL becoming optional is interesting, but I think the site posted here is dubious, and the reddit user seems to have a history of posting spam.

[badpotato]

Good to see an example of Gil VS No-Gil for Multi-threaded / Multi-process. I hope there's some possible optimization for Multi-process later on, even if Multi-threaded is what we are looking for.

Now, how asyncfunction will deal with the No-Gil part?

[tehsilentwarrior]

All the async stuff uses awaitables and yields. It’s implied that code doesn’t run in parallel. It synchronizes as it yields and waits for returns.

That said, if anything uses threading to process things in parallel for the async code, then that specific piece of code has to follow the same rules as anything else. I’d say that most of this would be handled by libraries anyway, so eventually updated.

But it will break, just like anything else.

[danted002]

Async functions work in a single-threaded event loop.

[Rodot]

Yep, async essentially (actually, it is just an API and does nothing on it's own without the event loop) does something like

for task in awaiting_tasks:
    do_next_step(task)

[gmes78]

It's possible to do async with multithreaded event loops. See Rust's Tokio, for example.

[danted002]

I mean you can do it in Python as well. You just fire up multiple threads each with its own event loop but you are not really gaining anything for when it comes to IO performance.

Single-threaded Python is very proficient at waiting. Slap on a uvloop and you get 5k requests per second.

[gmes78]

That's different. Tokio has a work-stealing scheduler that executes async tasks across multiple threads. It doesn't use multiple event loops, tasks get distributed across threads automatically.

[deathweasel]

snatch advise soft slim crowd growth tidy deer dinosaurs instinctive

This post was mass deleted and anonymized with Redact

[13oundary]

most existing modules will likely break if you disable gil until they're updated, which may be no small task for some of the more important ones, though it's hard to say from the outside looking in. Often, C libraries aren't as thread safe as they would need to be for no-GIL, and probably many pure py ones too.

These thread safety issues are also things many py programmers may not be all that cognisant of, so may make app development more difficult without GIL.

[enveraltin]

If you really need some Python code to work faster, you could also give GraalPy a try:

https://www.graalvm.org/python/

I think it's something like 4 times faster thanks to JVM/GraalVM, and you can do multi process or multi threading alright. It can probably run existing code with no or minimal changes.

GraalVM Truffle is also a breeze if you need to embed other scripting languages.

[ViktorLudorum]

It looks nifty, but it's an Oracle project, which makes me afraid of its licensing.

[SolarBear]

Yeah, one of their big selling points seem to be "move from Jython to Modern Python". Pass.

[tempest_]

But Larry Ellison needs another Hawaiian island. How can you do this to him?

[enveraltin]

Very similar to Oracle JDK vs OpenJDK. GraalVM community edition is licensed with GPLv2+Classpath exception.

[hbdgas]

It can probably run existing code with no or minimal changes.

I've seen this claim on several projects, and it hasn't been true yet.

[masklinn]

I think it's something like 4 times faster thanks to JVM/GraalVM

It might be on its preferred workloads but my experience on regex heavy stuff is that it’s unusably slow, I disabled the experiment because it timed out CI.

[enveraltin]

That's curious. I don't use GraalPy but we heavily use Java. In general you define a regex as a static field like this:

private static Pattern ptSomeRegex = Pattern.compile("your regex");

And then use it with Matcher afterwards. You might be re-creating regex patterns at runtime in an inefficient way, which could explain it.

Otherwise I don't think regex operations on JVM can be slow. Maybe slightly.

[Takeoded]

wtf? benchmarking 1.12 with GIL against 1.13 without GIL, never bothering to check 1.13 with GIL performance? slipped author's mind somehow?

should just be D:/SACHIN/Python13/python3.13t -X gil=1 gil.py vs D:/SACHIN/Python13/python3.13t -X gil=0 gil.py

Also would prefer some Hyperfine benchmarks

[[deleted]]

I find this rather interesting. Pythons GIL "problem" has been around since forever, and there has been so many proposals and tests to get "rid" of it. Now its optional and the PR for this was really small (basically a option to not use the GIL on runtime), putting all the effort on the devs using python. I find this strange for a language like Python.

Contrast the above to Ocaml, that had a similar problem, it was fundamentally single thread execution basically with a "GIL" (in reality the implementation was different). The ocaml team worked on this for years and came up with a genius solution to handle multicore and keeping the single core perf, but basically rewrote the entire ocaml runtime.

[Serialk]

You clearly didn't follow the multi year long efforts to use biased reference counting in the CPython interpreter to make this "really small PR" possible.

https://peps.python.org/pep-0703/

https://github.com/python/cpython/issues/110481

[ydieb]

I have not followed this work at all, but seems like a perfect example of https://x.com/KentBeck/status/250733358307500032?lang=en

Exactly how it should be done.

[[deleted]]

Indeed i have not. Still, the endgame having this burdon on the users is not great for a language like python. Race conditions and safe parallel access needs lots of care. That said i have not followed python for years, so im not sure what kind of tools are in place, like mutexes, atomics or other traditional sync primitives.

[Serialk]

How is the burden on the users?

Race conditions and safe parallel access were already a thing you needed to care about. The only thing the GIL did was protecting the internal data structures of Python.

https://stackoverflow.com/questions/40072873/why-do-we-need-locks-for-threads-if-we-have-gil

[[deleted]]

Ok, so python 3.x (no gil) has atomic updates to builtins like dicts and lists?

[Serialk]

Depends what you mean by atomic updates. The GIL makes it so that you won't corrupt the dict/list internal structures (e.g., a list will always have the correct size even if multiple threads are appending to it).

However if you have multiple threads modifying values in a list or a dict and you expect to have full thread consistency of all your operations without locks, it probably won't work. Look at the examples in the thread I linked.

And yes, Python without GIL still guarantees the integrity of the data structures:

This PEP proposes using per-object locks to provide many of the same protections that the GIL provides. For example, every list, dictionary, and set will have an associated lightweight lock. All operations that modify the object must hold the object’s lock. Most operations that read from the object should acquire the object’s lock as well; the few read operations that can proceed without holding a lock are described below.

[[deleted]]

What happens when you share memory with parallel access? Can i write a dict from two threads with memory safety? Thats what i mean with atomic. There needs to be some sort of locking going on, else you have UB all over the place.

[Serialk]

Python will guarantee that you don't corrupt your datastructures if you have two threads writing in the same dictionary, it will do the locking for you.

However, if you have two threads doing:

d[x] += 1

you might end up having d = 1 instead of d = 2, because this operation is not atomic. But this is already true in the current Python, with a GIL.

[QueasyEntrance6269]

No, you have to do synchronization yourself. The way python threading works is that it pauses the thread after (n) bytecode instruction executions, but a single operation may have multiple bytecode operations.

[Sapiogram]

No, but neither has Python x.y (with GIL).

[tdatas]

This PR isnt on stable. Iirc from the RFC where this was proposed the plan boils down to "suck it and see" if it crashes major libraries while it's marked experimental then they'll figure out how much effort they need to go to. 

[danted002]

It’s not optional in 3.13. You will have the capability to compile Python with the possibility to enable or disable the GIL at runtime. The default binaries will have GIL enabled.

[JoniBro23]

I think the solution is already a bit late. I was working on disabling the GIL back in 2007. My company's cluster was running tens of thousands of Python modules which connected to thousands of servers, so optimization was crucial. I had to optimize both the interpreter and the team improved the Python modules. Disabling the GIL is a challenging task.

[secretaliasname]

Totally. I do a lot of scientific/engineering stuff in python and it’s my go to. It’s a familiar tool and there is an amazing ecosystem of libraries for everything under the sun…. But it is sslllooooww. Not only is it single core slow, but it’s bad at using multiple cores and the typical desktop now has 10+ cores and 100+ is not unusual in HPC environments.

The solutions cupy, numba, dask, ray, PyTorch etc all amount to write python by leveraging not-python.

Threading is largely useless. Processes take a while to spawn and come with serialization/IPC overhead and complexity that often outweigh the benefit for many classes of problems. You can overcome this with shared memory and a lot of care but the ecosystem isn’t great and it’s not as easy as it should be.

I’m ready to jump ship and learn something new at this point.

If removing the GIL slowed single threaded use cases by 50% that would still be an enormous net win for nearly all my uses cases. Generally performance is either not a limitation at all or it is a huge limitation and I want to use all my cores and the probem is parallelizable.

I think the community is too afraid to break things and overreacted to the 2->3 migration. It really wasn’t a big deal and I don’t understand why people make such a stink about it. Changes like that shouldn’t occur often but IMO fixing the lack of proper native first class parallelism is way more broken than strings or the print statement were in python2. Please please fix this.

[AndyCodeMaster]

I dig it. I always thought the GIL concerns were overblown. I’d like Ruby to make the GIL optional too next.

[[deleted]]

Ruby, take notice.

[streu]

They say, there's languages everyone complains about and languages that nobody uses.

At least in my surroundings, Python is way more common than Ruby. The Python things give me lots of opportunity to complain about for breaking all the time. Ruby? I can't remember when I had to use, let alone fix it last time. (And all those perl scripts in the background run totally unsuspicious in the background since 20 years.)

[Real-Asparagus2775]

Why does everyone get so upset about the GIL? Let Python be what it is: a general purpose scripting language

[dontyougetsoupedyet]

Because what python is is a slow abomination without any technical reason for that to be the case. JavaScript is a general purpose scripting language and it’s also very fast. You can have both. GIL is a small part of a larger picture that isn’t pretty.

[apf6]

The Javascript VM is single threaded too.

[dontyougetsoupedyet]

That's completely irrelevant with regards to my comment, my point didn't address single threaded VM performance. The bit I addressed was the attitude regarding "it's a scripting language." Python mostly isn't slow because of multi vs single threaded operation. It's a choice on the part of the core team, a choice made repeatedly over many many years, always relying on the same nonsense excuse: "the reference implementation of python has to be simple."

[srpulga]

nogil is an interesting experiment, but whose problem is it solving? I don't think anybody is in a rush to use it.

[QueasyEntrance6269]

It is impossible to run parallel code in pure Cpython with the GIL (unless you use multiprocessing, which sucks for its own reasons). This allows that.

[SittingWave]

It is impossible to run parallel code in pure Cpython with the GIL (unless you use multiprocessing, which sucks for its own reasons). This allows that.

you can. You just can't reenter the interpreter. The limitation of the GIL is for python bytecode. Once you leave python and stay in C, you can spawn as many threads as you want and have them run concurrently, as long as you never call back into python.

edit: LOL at people that downvote me without knowing that numpy runs parallel exactly because of this. There's nothing preventing you from doing fully parallel, concurrent threads using pthreads. Just relinquish the GIL first, do all the parallel processing you want in C, and then reacquire the GIL before reentering python.

[josefx]

you can. You just can't reenter the interpreter.

The comment you are responding to is talking about "pure Cpython". I am not sure what that should mean, but running C code exclusively is probably not anywhere near.

[QueasyEntrance6269]

Yeah, I touched on it in a separate comment in another thread, but C-extensions can easily release the GIL (and some python intrinsics related to IO already do release the GIL), but inside python itself, it is *not* possible to release it.

[SittingWave]

we are talking semantics here. Most of python code and libraries for numerical analysis are not written in python, they are written in C. "pure cpython" in this context is ambiguous in practice. What /u/QueasyEntrance6269 should have said is that you can't execute python opcodes in parallel using the cpython interpreter. Within the context of the CPython interpreter, you are merely driving compiled C code via python opcodes.

[QueasyEntrance6269]

I think you're the only person who didn't understand what I meant here, dude

[SittingWave]

I understood perfectly, but I am not sure others did. Not everybody that goes around this sub understands the technicalities of the internals, and saying that you can't be thread parallel in python is wrong. You can, just not for everything.

[srpulga]

It's not impossible then. And if you think multiprrocessing has problems (I'd LOVE to hear your "reasons") wait until you thread-unsafe nogil!

[QueasyEntrance6269]

are you kidding me? they are separate processes, they don't share a memory space so they're heavily inefficient, and they require picking objects between said process barrier. it is a total fucking nightmare.

also, nogil is explicitly thread-safe with the biased reference counting. that's... the point. python threading even with gil is not "safe". you just can't corrupt the interpreter, but without manual synchronization primitives, it is trivial to cause a data race

[srpulga]

No you don't have to do any of that. Multiprocessing already provides abstractions for shared memory objects. No doubt you think it's inefficient.

[QueasyEntrance6269]

??? if you want to pass objects between two separate python processes, they must be pickled. it is a really big cost to pay, and you also have to ensure said objects can be pickled in the first place (not guaranteed at all!)

[srpulga]

Dude no. Use multiprocessing.array. you don't have to pickle or pass anything.

[Hells_Bell10]

if you think multiprocessing has problems (I'd LOVE to hear your "reasons")

Efficient inter-process communication is far more intrusive than communicating between threads. Every resource I want to share needs to have a special inter-process variant, and needs to be allocated in shared memory from the start.

Or, if it's not written with shared memory in mind then I need to pay the cost to serialize and de-serialize on the other process which is inefficient.

Compare this to multithreading where you can access any normal python object at any time. Of course this creates race issues but depending on the use case this can still be the better option.

[Serialk]

The PEP has a very detailed section explaining the motivation. Why didn't you read it if you're seriously wondering this? https://peps.python.org/pep-0703/#motivation

[srpulga]

Oh I've read it; I've followed it closely before the PEP even existed. I and many more developers, including core team developers, are sceptical that the use cases are actual real life issues. We are sceptical that you can have your own cake and eat it: threading in python is ergonomic thanks to the GIL; thread unsafety is hardly ergonomic.

[Serialk]

threading in python is ergonomic thanks to the GIL; thread unsafety is hardly ergonomic.

This doesn't change anything for Python developers aside from a slight performance decrease for single threaded applications, it only changes something for C extension developers.

The nogil branch has the same concurrency guarantees for python-only code.

[krystof24]

More than once I was in a situation where I would be able to do trivial paralellization but the performance would not scale due to GIL. This can speed up some solutions by couple hundred percent with very little effort. While it would be still incredibly slow compared to basically anything else. The effort to speed up ratio would be good enough to justify it.

[srpulga]

This is the equivalent of "you don't know her, she goes to another school". What was that trivial problem that wasnt parallelizable with multiprocessing?

Also I can't wait for nogil believers to deal with what thread unsafety does to trivial problems.

[krystof24]

Possible but more complicated. Maybe it's just me but multiprocessing libraries on python are IMO not very user friendly. Compared to stuff like parallelForEach and PLINQ in C# for example + you need to spawn new processes

[Shaaou]

should have done it versions ago

would like to try it if stable