Python stands to lose its GIL, and gain a lot of speed

https://www.infoworld.com/article/3637073/python-stands-to-lose-its-gil-and-gain-a-lot-of-speed.html

by bobajeff • 5 years ago

343 345 5 years ago

infoworld.com

di• 5 years ago

Previous discussion: https://news.ycombinator.com/item?id=28880782

Animats• 5 years ago

Yes. This is the discussion we had yesterday, but with more hype.

np_tedious• 5 years ago

These changes are major enough that a fair number of existing Python libraries that work directly with Python’s internals (e.g., Cython) would need to be rewritten. But the cadence of Python’s release schedule just means such breaking changes would need to be made in a major point release instead of a minor one.

Maybe time to rethink? https://www.techrepublic.com/article/programming-languages-w...

If this is as promising as it sounds, it seems Python 4 now has its "thing" and is on the horizon. Or at least may become a serious thing to talk about

dangerbird22• 5 years ago

I'd wonder if it would be easier to introduce a totally new API along the lines of ruby's ractor API[1] that enables thread parallelism while keeping existing Thread behavior identical as with the GIL. Tons of python code relies on threaded code that is thread-safe under the GIL, but would completely blow up if the GIL was naively replaced.

[1] https://docs.ruby-lang.org/en/master/doc/ractor_md.html

arthurcolle• 5 years ago

Ractors don't offer very good performance yet. Better to have it be awesome right off the bat

gwking• 5 years ago

I began using python during the python3.0 betas, and I watched the 2 vs 3 saga from the (unusual?) perspective of a v3 hobbyist with no back-compat requirements.

What struck me as most significant was the opportunistic breakage of things not related to the unicode transition. In the many years it took to win people over to v3, they could have marched over all the breaking changes a year at a time. Given that side-by-side installs of python3.x point versions are very functional, with or without venvs, this would have been much more palatable. Perhaps harder than it sounds though.

I attempted a couple of 2to3 translations of open source libraries over the years, with varying degrees of success. Every time I found that most of the changes were easy, but debugging the broken bits was hard due to the sheer volume of source changes. If instead I could have done conversions where there was only a single major semantic change at a time, it would be so much easier to figure out what was going wrong at any given step. Furthermore, I imagine that a single-breaking-change mentality would lead to better documentation on how to transition for each version.

For this reason, I have become rather suspicious of yearly release schedules. Swift is even more frustrating: the version changes are really just dictated by Apple's yearly PR calendar. Some big things get rushed out for WWDC before they are ready, and smaller fixes can get held back until the next year. I would much rather that the language teams just prioritize one thing at a time, release it when it is ready, and foster a community where staying up-to-date on the latest version is easy and desirable (a more complicated story for Apple than for Python I think, due to ABI, OS version, etc).

From past discussions on HN I've gathered that there is such a thing as release fatigue, where developers get irritated when libraries release breaking changes too often. Nevertheless I often wonder if languages and libraries could improve faster by making more breaking changes, one at a time, with robust side-by-side installs to facilitate testing across versions. I wish side-by-side library versions were possible in Python, just to facilitate regression testing.

Bringing this all back to the post, I sincerely hope that if Python 4 is a breaking change to the GIL, that it will be only that.

I'm curious what others think about all this. Thoughts?

kevin_thibedeau• 5 years ago

If instead I could have done conversions where there was only a single major semantic change at a time,

That was the point of the "from __future__" imports. You could get most of the way toward Python 3 so that 2to3 would be easier to work with and the new semantics could be gradually baked into the code prior to migration.

Python 3 had 25 years of cruft to clean up. They won't have to do that again.

fractalb• 5 years ago

If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. People will just be scared of new releases. No one will adopt a new language version as soon as it releases. Java never breaks backwards compatibility and still there are people running Java 8. Imagine what would happen if every point release carries breaking changes. It makes you feel that the language is not mature, the library ecosystem broken, since you'll have to keep track of version compatibility for each library that you use. It's a nightmare for both library developers and end-users. Few people would like to use such a language

xvland• 5 years ago

Idealists and free developers (who have created the majority of the Python interpreter) agree with you.

Corporate developers, who have taken over Python and other people's work, like unnecessary changes, because they get many billable hours of seemingly complex work that can be done on autopilot.

Corporations might even take over more C extensions whose developers are no longer willing to put up with the churn and who have moved to C++ or Java.

In the long run, this is bad for Python. But many developers want to milk the snake until their retirement and don't care what happens afterwards.

isoprophlex4• 5 years ago

O boy, angry rant incoming. I'll say something petulant and overly dramatic, but I don't like the direction in which python is going, and I'm glad there's finally some news about focus on actual innovation instead of tacking on syntactic cruft.

I want the python that Guido promised me, with 2021 performance. I don't want some abhorrent committee-designed piece of middle-of-the-road shitware glue language that I must use because everyone uses it.

I want a language that doesn't spin it's single-threaded wheel in a sea of CPU cores, and I want a language that has one obvious way of doing things without needing to grok and parse dumb """clever""" hacks that will only be abused by midlevel programmers to show off hoe they saved typing a few lines of additional code.

To me, speed + simplicity = ergonomy = joy. I want a new python 4 to focus exclusively and intensely on performance improvements and ergonomy.

klyrs4• 5 years ago

Cython itself should be a relatively simple fix (relative to the difficulty that Cython devs are accustomed to). Libraries that use Cython in a pure way (that is, not fussing with refcounts in hand-written C code) should "just work" after Cython gets updated. It's the poor folk who have done straight C extensions without the benefit of Cython that I'm concerned about.

lpapez• 5 years ago

A simple solution would be to introduce two new types: ConcurrentThread and ParallelThread. Alias the old Thread to the ConcurrentThread and keep the behaviour. No breaking changes, easy to explain the differrence. People who need it can use the new truly parallel version.

randtrain34• 5 years ago

Design doc the proposer linked: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD...

lvass4• 5 years ago

I have seen and written Python code that spawns various threads with shared mutable state. Is it possible that some day the same code would run in parallel? That could be a terrible (very) breaking change. I'm not against allowing in-process parallel execution but please let it require a new API.

ajkjk6• 5 years ago

Isn't that.. Already the case? The gil doesn't prevent thread switching in the middle of python code.

lvass4• 5 years ago

It's concurrent not parallel. The switch won't happen inside the execution of one opcode including some dictionary update operations so it's safe in many cases where parallel execution isn't.

pkulak2• 5 years ago

That was my first thought as well. I use Python to whip up quick scripts and enjoy not having to worry about shared memory, even when I'm using concurrency. I'd hate to lose that.

Spivak3• 5 years ago

Don’t you still have to worry about this since OS threads can be arbitrarily preempted?

juanbyrge• 5 years ago

Translation: I have written buggy, racy software that has specific dependencies on thread timing. Please do not make significant improvements to Python because it will reveal these bugs in my software, and I will be forced to fix the bugs and use proper synchronization.

lvass4• 5 years ago

Is that how you call things that have been working flawlessly and solving people's problems for over 10 years? Is needlessly breaking things that work an improvement to you?

lazide10• 5 years ago

If you make something that works because of an explicit memory and concurrency model (and not like there are other options at the time), it is indeed legit to worry about a major shift to those models that would cause problems.

Even if those changes are better for other ways of solving problems.

TekMol5• 5 years ago

Why is multithreaded performance important, what are the usecases where you cannot run multiple processes to spread your numbercrunching across CPUs?

I am praying for CPython to become faster. But I need faster singlethreaded performance, so web applications benefit from it.

chrisseaton2• 5 years ago

Communicating between processes is more expensive than communicating between threads.

TekMol5• 5 years ago

Ok, but what is the use case where you need high bandwidth inter-thread/process communication?

VWWHFSfQ• 5 years ago

multiple processes use a lot more memory than threads

TekMol5• 5 years ago

Can you quantify that?

rbjorklin• 5 years ago

One thing that comes to mind is for shared connection pools when you have thousands of workers connecting to the same stateful service.

TekMol5• 5 years ago

Which use case requires such a setup?

lostdog• 5 years ago

Here's a use case: I was training a neutral net, and wanted to do some preprocessing (similar to image resizing, but without an existing C function). Inputs are batched, so the preprocessing is trivially parallelizable. I tried to multithread it in python, and got no speedup at all.

That was a really sad moment, and I've never felt good about python since.

isoprophlex4• 5 years ago

Yeah, I had something similar.

I wanted "as you wait for the GPU to churn through this batch, start reading the next batch from disk & preprocessing it on the CPU"

Getting this to work turned out so ass backwards it made me sad

Also I pity the fool who tries to connect a debugger to code using multiprocessing.Pool()...

redeyed5• 5 years ago

Yeah, had the exact problem.

I solved it by using python threads and C function (cv2.resize)

kzrdude4• 5 years ago

Interactive use of Python: plotting, working with data, also would benefit from better multithreading. It's interactive, so it's (a bit) frustrating to wait for it to compute and see that it uses just one thread (the statistics ops are usually well threaded already, but plotting is not).

dleslie2• 5 years ago

I wonder how many folks think they're writing thread safe software with ease, and are unaware that they are leaning on the GIL?

Could be that the impact of this change is far broader than just a few key libraries.

avianlyric2• 5 years ago

I don’t see how the GIL makes writing thread safe software any easier. The GIL might prevent two Python threads executing simultaneously, but it doesn’t change the fact that a Python thread can be preempted, meaning your global state can change at any point during execution without warning.

Most of the issues with multi-threading come from concurrency, not parallelism. The GIL allows concurrency, you just don’t get any of the advantages of parallelism, which is normally the reason for putting up with the complexity concurrency creates.

dleslie2• 5 years ago

The GIL might prevent two Python threads executing simultaneously, but it doesn’t change the fact that a Python thread can be preempted, meaning your global state can change at any point during execution without warning.

That thread behavior is enough to reduce the likelihood of races and collisions; particularly if the critical sections are narrow.

chacham15• 5 years ago

There are certain classes of errors that it prevents. E.g:

Thread1: a = 0xFFFFFFFF00000000

Thread2: a = 0x00000000FFFFFFFF

One might think that the two possible values of a if those are run concurrently are 0xFFFFFFFF00000000 and 0x00000000FFFFFFFF. But actually 0x0000000000000000 and 0xFFFFFFFFFFFFFFFF are also possible because the load itself isnt atomic.

The GIL (AFAICT) will prevent the latter two possibilities.

dehrmann2• 5 years ago

It's more cpython than the GIL, but it lets you get away with using += and certain dict operations without locks.

stefan_• 5 years ago

From running the same software on two moderately powerful embedded systems, one single-core and one multi-core, the latter is a lot more reliable in immediately exposing races and concurrency issues.

hyperbovine• 5 years ago

Conversely, I have found that the GIL makes it unexpectedly easy to write thread-safe software in Python. Compare (in Cython) writing

   with gil:
       call_a_method()
       print(some_debugging_info)

with all the sit-ups you’d have to do in a “real” concurrent language.

ynik3• 5 years ago

The GIL doesn't really help Python code though, because the interpreter may switch threads between any two opcodes.

It only protects the state of the Python interpreter and that of C/Cython extension modules. Though even there, you can have unexpected thread switches, e.g. in Cython `self.obj = None` can result in a thread switch if the value previously stored in `self.obj` had a `__del__` method implemented in Python.

And AFAIK pretty much any Python object allocation can trigger the cycle collector which can trigger `__del__` on (completely unrelated) objects in reference cycles, so it's pretty much impossible to rely on the GIL to keep any non-trivial code block atomic.

rectang• 5 years ago

I have read many anti-GIL arguments over the years that approach soundness as optional. Is this change going to make a bunch of previously sound code unsound?

jnxx• 5 years ago

I have seen that once in supposedly thread-safe C++ software in an industrial automation application. What happened was that it was somehow relying on the Windows UI messaging system (the message pump) which is single-threaded, and the fact that there were no multi-core CPUs when that stuff was written a long time ago. The latter has the effect that the CPU always sees a consistent view on the memory, no locks, mutexes and barriers needed.

Porting the thing to a multi-core system revealed that there were a lot of nasty concurrency bugs, like dead-locks or crashes which happened after a day of operation. And this wasn't a toy system - it was in use for a long time in an industrial application, and the customer was not too happy about the intermittent dead-locks. I commiserated with the poor engineer who had the quite stressful task to debug this, equipped with a lot of dedication but an insufficient background.

Frankly, while it would be nice to be able to write parallel code in pure Python, I think that Clojure with its purely-functional approach has the better concepts for this. And moreover, actually improving performance by parallel computation (using several CPUs to work in parallel on the same thing) is damn hard and unsolved in many cases (just come up with an efficient parallel Fast Fourier Transform and you might get a Turing award). What is mostly needed (outside of massive data processing pipelines) is concurrency for event-driven systems. Python can handle that, Clojure does handle it in a much more elegant way.

mhh__2• 5 years ago

With all the effort that's been put into this how many people just jumped ship to a native/more-native language?

I'm probably biased because I think Python is a hacked together mess but I just don't see what the point is in dragging it around.

jgb1984• 5 years ago

Very useful contribution, thanks! Mainly to demonstrate your own ignorance on the topic at hand.

mhh__2• 5 years ago

I did ask a question. The second part is me being belligerent but the question was sincere.

I think Python is shit but so is most everything else, I'm interested in whether people jump ship or just work around it's issues at scale. I work on a programming language designed to avoid messy python scripts internally, so I am sincerely interested in these decisions.

ajkjk6• 5 years ago

The difference is that it is so much easier, by orders of magnitude, to write code that gets shit done in python than any native language I'm aware of.

Zababa• 5 years ago

With all the effort that's been put into this how many people just jumped ship to a native/more-native language?

I think Go benefited a lot from that.

redeyed5• 5 years ago

Again hammer to microscope comparison. Do you realize that your ignorance is bigger than Solar System?

Mikeb85• 5 years ago

I use Ruby and not Python, but I think both have a lot of the same benefits and weaknesses.

IMO, removing the GIL is a major mistake. The GIL is what allows you easy concurrency and to keep the language's 'magic' while ensuring correctness. If you need parallelism, there's processes and probably other tactics (I'm not super up to date on Python things). If you simply remove the GIL you have a bunch of race conditions, so you need a bunch of new language constructs, and it just adds a bunch of complexity to solve problems that don't really need solving.

IMO they should just do what Ruby did with Ractors; basically a cheap alternative to spawning more processes. Rewriting absolutely everything that uses threads to be thread-safe is a waste of time.

klyrs4• 5 years ago

It's already easy to write race conditions in Python.

  if x in d:
      del d[x]
  else:
      d[x] = True

Is a classic example -- if two threads execute that, you can't predict the outcome (but a KeyError is quite likely)

The GIL only protects the CPython virtual machine; it doesn't protect user code. Concurrent code with shared mutable state already needs explicit mutexes.

intrepidhero2• 5 years ago

What thread safe code can I write with the GIL that will have a race without it?

I already have to be careful to only write to a shared object from one thread, since I have no guarantees on order of execution.

The main benefit of the GIL, from my recent reading is that it makes ref counting fast and thread safe. The meat of the proposal is changing ref counting so that it's almost as fast and atomic without the GIL.

ptx3• 5 years ago

What about setting a simple boolean flag, e.g. setting "cancelled = True" in the UI thread to cancel an operation in a background thread?

In Java you would have to worry about safe publication to make the change visible to the other thread, but thanks to the GIL changes in Python are always (I think?) made visible to other threads.

Mehdi22773• 5 years ago

No new race conditions are expected as this work replaces Gil with finer grained performant locks. It still lowers performance of single threaded code some vs no Gil (about 10 percent) but 10 percent drop in single threaded performance is worth considering for multi threading.

The race conditions a Gil program and a no Gil program should have should be same. A Gil is not the only way to keep certain operations safe.

celeritascelery• 5 years ago

but 10 percent drop in single threaded performance is worth considering for multi threading.

Only if you are writing multithreaded coded. Otherwise it is just a loss.

jillesvangurp• 5 years ago

The GIL is not a feature but a design problem with both Ruby and Python. Implementations of both without a GIL have existed for quite long (e.g. jvm based implementations like jython and jruby). It's fine; not having a GIL is an enabler. E.g. being able to run ruby on rails on an application server with threads for each connection used to be a popular thing. I've migrated a few ruby things to jruby. It's shockingly easy. Mostly stuff just works.

The nice thing about everything being single threaded is that nothing will break if you remove the GIL. It will still be single threaded. It's only when you actively start using multiple threads that things might break. So, you won't have race conditions until you do that and then only if you do things that you shouldn't be doing like sharing things across threads that you should not be sharing because they aren't thread safe.

Removing the GIL will simply enable people to start gradually fixing things and give them the option to use threads instead of forcing them to use completely different languages.

Ractor style asynchronous programming might be a good idea for python as well. One does not exclude the other.

gigatexal• 5 years ago

These are the kinds of moves Python needs to stay relevant with amazing languages like Go out there that are just so simple yet powerful.

sys_64738• 5 years ago

Knowledge of the GIL forces a lot of python developers to not try to write multithreaded scripts. Doing away with it will make life harder for many folks, IMO. Have you tried explaining multithreading to some python scripters?

aasasd• 5 years ago

I mean, it stands to evolutionary reason that Python shouldn't have a GIL.

aeturnum5• 5 years ago

I worked in Python for years and while I suppose I'm glad for any improvement, I have never understood the obsession with true multi-threading. Languages are about trade-offs and Python, again and again, chooses flexibility over performance. It's a good choice! You can see it in how widely Python is used and the diversity of its applications.

Performance doesn't come from any one quality, but from the holistic goals at each level of the language. I think some of the most frustrating aspects from the history of Python have been when the team lost focus on why and how people used the language (i.e. the 2 -> 3 transition, though I have always loved 3). I hope that this is a sensible optimization and not an over-extension.

klyrs4• 5 years ago

Losing the GIL strictly makes the language strictly more flexible. Previous GILectomies tanked performance to an unacceptable degree. In single-threaded code, this one is a moderate performance improvement in some benchmarks, and a small detriment in others -- which is about as close to perfect as one could expect from such a change. That's why people are excited about it.

At a higher level, Python is getting serious about performance. But this gives both flexibility and performance.

aeturnum5• 5 years ago

Yah, that's definitely the future I'm hoping for. What I am worried about are the kind of transition issues I mentioned. Python 2 -> 3 strictly made the language more flexible too - but the Python ecosystem is about existing code almost more than the language and I worry that we could find similar problems here. Potential for plenty of growing pains while chasing relatively small gains.

gshulegaard3• 5 years ago

Call me optimistically skeptical. I share similar reservations about GIL obsession with the original comment author, but if this is true:

The overall effect of this change, and a number of others with it, actually boosts single-threaded performance slightly—by around 10%

Then it sounds like having the cake and eating it too (optimism). Although my experience keeps nagging at me with, "there is not such thing as a free lunch" (skepticism).

xiaodai• 5 years ago

GIL will improve performance of multi-threaded code but the issue with Python performance is single-threaded code and its rich object system.

Can't see Python getting there unless we go to Python 4 which, given the fiasco that was Python 2->3 is probably never gonna happen.

Might as well wait for Julia to improve its TTFP then to hope for a Python 4.

birdyrooster2• 5 years ago

Python needs to be compiled into machine language to ever have a chance of competing on speed. We can already get around the GIL with multiprocess but Python is still to slow even when not bound by copying memory between processes.

amelius• 5 years ago

Performance doesn't come from any one quality, but from the holistic goals at each level of the language.

It starts to become an issue when you have built a few well-performing subsystems and now want them to run together and interact. With the GIL, your subsystems are suddenly not performing as well anymore. Without the GIL, you can still get good performance (within limits of course).

Performance referring here to throughput and/or latency (responsiveness).

tester756• 5 years ago

again and again, chooses flexibility over performance. It's a good choice! You can see it in how widely Python is used and the diversity of its applications.

What does it mean? how is python different here than Java/C#?

aeturnum5• 5 years ago

I mean, you can modify Python code at runtime if you like. This has a good overview of all the nonsense happening under the hood: http://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/

cma3• 5 years ago

There are 64-core, 128-thread prosumer CPUs now and it is only going to go higher. At some point it just becomes necessary.

turminal3• 5 years ago

What does a 128 thread python app do better than 128 single threaded ones?

aeturnum5• 5 years ago

Yes higher core counts are more and more common, but the language has thirty years of single-threaded path-dependence. Lots of elements of it work the way they do because there was a GIL. I could be wrong, but I am skeptical that Python will ever be the best choice for high performance code. It's always worth improving the speed of code when you can, but more often than not you "get" something for going slower. I hope my worries are wrong and this is actually a free win!

darthrupert3• 5 years ago

Lack of multithreading can easily be a win for a language. A tiny subset of problems really needs it these days and for everything else it's a potential way to either screw things up or make them way more complicated that needs to be.

cm21873• 5 years ago

A tiny subset of problems

like processing web requests?

emrah• 5 years ago

So if you don't like it or want it, don't use it then? Why does it have to be missing altogether for you to be happy?

cm21873• 5 years ago

Popularity has probably as much to do, if not more to do, with ease of access (or lack of alternative) than good design of the language. Php is equally if not more popular than python.

aeturnum5• 5 years ago

I'm not a PHP expert, but I did not know it was also used in data science, game programming, embedded programming and machine learning as Python is. Of course they are both used for web services.

emerged• 5 years ago

From my perspective as a huge Python fan, efficient multithreading is simply the only major thing missing from the language. I would still use C/C++/assembly for bleeding edge performance needs, but efficient multithreading in Python would have me reaching for alternatives far less often.

Basically I love peanut butter ice cream (Python) I’d just like it even more with sprinkles.

dec0dedab0de3• 5 years ago

I agree, but I don't do anything that can be split up, and would benefit from sharing memory. That is really the only benefit of removing the GIL. Multiprocessing can do true concurrency, and so can Celery, which even allows you to use multiple computers. The only time that is a pain is when you need to share memory, or I guess maybe if you're low on resources and can't spare the overhead from multiple processes.

I think a JIT would be the best possible improvement for CPython as far as speed is concerned. Though I can imagine there are plenty of people doing processor heavy stuff with c extensions that would benefit from sharing memory. So from their perspective removing the GIL would be a better improvement.

So basically a JIT would help every Python program, and removing the GIL would only help a small subset of Python programs. Though I'm just happy I get to make a living using Python.

Edit: This was in the back of my head, but I didn't mention it, and it would be unfair to dismiss. A JIT does slowdown startup time, so for short programs that are finished running quickly it may make things worse. Though I suspect it would be easy enough to have a value to turn off the JIT at the start of the program.

phkahler4• 5 years ago

> So basically a JIT would help every Python program, and removing the GIL would only help a small subset of Python programs.

What if the "Global Interpreter Lock" needs to be removed for JIT? I put that in quotes to highlight it because AFAICT no compiled (or JITed) language has such a thing. I think it functions differently than regular stuff like critical sections.

lelandbatey• 5 years ago

Pythons existing threading support (via the threading module) can already do true concurrency just fine. Concurrency and parallelism are not the same thing. The GIL limits parallelism, making separate OS threads operate concurrently but not in parallel. Removing the GIL will allow threads in python programs to operate concurrently and in parallel.

https://go.dev/blog/waza-talk

m0zg• 5 years ago

One does not preclude another: the language can be flexible and offer higher concurrency that it does now. My workstation has 64 hyperthreads. Python can use one at a time. That's messed up since I use it as a general purpose language.

didip• 5 years ago

This is because Python, by luck, ended up dominating the data science market.

In this market you really want to shuffle tons of data quickly, and that’s usually achieved through parallelism.

Python multiprocess library does a poor job at that.

anthk• 5 years ago

That's calling C and Fortran in the background, actually.

mechanical_bear• 5 years ago

By luck? I think that is a bit reductionist.

heavyset_go3• 5 years ago

It's because threads in Python are only really good for parallel I/O, and are ineffective for CPU bound workloads.

This can be a problem for a lot of treading use cases. If I'm working on an ETL app that parses large amounts of data, either the related CPU bound tasks need to either run sequentially, call out to C extensions, or use multiple processes which incurs an overhead.

It's a pain when you know threads would suit your use case well, but the threading implementation in the language you're working in isn't up to the task.

Godel_unicode• 5 years ago

While it would be nice to have the language be able to do it, the fact that you can't today leads to some tidy separation of concerns for parallelization. For instance, many people I've talked to use things like Spark or dask to get high scale on data processing tasks. That means that all of the management of distributed jobs is handled through an easily googleable framework that your ops team can manage, as opposed to needing to build all of that yourself.

I see this as being a nice stopgap solution for those who are too big for single-threaded but not big enough to need Spark.

ketozhang• 5 years ago

It's very interesting you mentioned ETL tasks. In ETL batch jobs, a unit in the batch is defined small enough to rarely be CPU bound; rather, as you mentioned, it is I/O bound. In what situation must you define a unit of work to be so heavily CPU bound? To me that's a smell for too large of a unit.

zone411• 5 years ago

Note that Python's poor single-threaded performance compared to single-threaded performance of other languages makes the ability to multi-thread that much more crucial. You can sometimes get away with 10x slower code but not 100x slower.

I've had to rewrite my Python code in another language in 3 different projects already (multi-processing wasn't an option) and I'm not even a heavy user. Removing GIL would be very welcome.

dragonwriter4• 5 years ago

You can sometimes get away with 10x slower code but not 100x slower.

That Python and other languages in its speed class are still used for new projects in production demonstrates that you can, often, get away with 100× slower code. But, sure, you can get away with 10× slower more often.

lmilcin• 5 years ago

The issue is people try to get throughput from Python and GIL stands in the way.

A lot of people learned Python and now want to use it for something more serious even if Python was not designed for it.

I work on high volume backends (like million TPS on a single node) and Python for me is just a toy language.

But I see no reason to purposefully inconvenience these people by keeping GIL if it can be removed.

Fiahil3• 5 years ago

Think about the datascience use case: you need to load data from disk or network as fast as possible and compute a lot of CPU-bound operations right after that.

Threads will allow you to split your I/O in multiple procedures, so you might start computations as soon as possible when the data is ready. They will also allow you to massively speed up aggregates without having to create a new process each time (which doesn't allow you to share memory). Threads are a BIG issue when you don't want to rely on asyncio[1].

Note [1]: Asyncio pools are single-threaded because of the GIL. This is already bad enough in practice, but they also perform very badly in CPU-bound contexts. This make them an absolute no-go when dealing with datascience code: a cpu-bounded core in an i/o-bounded wrapper.

alanfranz• 5 years ago

You can release the GIL in extensions, and a lot of datascience libraries do that, so not all python computations are single threaded.

karmasimida• 5 years ago

Removing GIL brings flexibility too.

Assuming now you have a big dictionary, which contains tens of millions of records to be filtered upon, another say TB of data. In current Python land, you either:

1. Using multi-processing, but each process needs to create its own dictionary

2. Or create an external DB, and using the DB's client to retrieve data in certain way.

This pattern has occurred again and again in my use case, and it is always messy to solve in Python. Had Python has true multi-threading, then sharing some big but read-only object among real threads would be a possibility, and believe me, a lot of people would be really happy.

heavenlyblue4• 5 years ago

Python uses a lot of memory, multi-threading makes you have only one process sharing all the same memory.

ngrilly• 5 years ago

Impressive proposal. That would remove a major limitation of CPython.

ahmedfromtunis2• 5 years ago

In my opinion, there's a time in a language's life were it should slow down the pace of "innovation". Code bases are complexe things and updating and upgrading them constantly just to keep up with the language maybe counterproductive.

Python is there now, if you ask me. It should slow down and focus more on "maintenance" stuff with little to no impact on its interface. And maybe work on big projects like multithreading or stronger typing on the background and them when they're fully ready.

pmlnr2• 5 years ago

stronger typing

Please, don't. There are wonderful strongly types languages out there, so if one wants or needs a strongly types language, use that, and not Python.

smitty1e2• 5 years ago

The gradual typing available now seems suitable. I have written plenty of code in typed contexts and plenty without. Python's "consenting adults" approach seems a win.

Perhaps, without the GIL and with typing information included, additional performance gains with be on offer.

But the "have it your way" nature of Python is a bigger win than either end of the data typing spectrum.

JacobHenner2• 5 years ago

Static typing, not strong typing

vram22• 5 years ago

pinch.take(salt)

Friend: I saw this interesting tech article ...

Me: Site?

Friend: mumble corp IT site mumble

Me: Bye

kzrdude4• 5 years ago

The story of losing GIL is very popular in the news, and I like it too!

.. but. Let's not count our chickens until they are home. I'm wondering if the Python dev community will take on this challenge. I hope so, Sam seems to really have put in a lot of effort!

haihaibye2• 5 years ago

FYI the saying is "count our chickens until they are hatched"

JacobHenner2• 5 years ago

Source: https://mail.python.org/archives/list/python-dev@python.org/...

pvg• 5 years ago

The other day:

https://news.ycombinator.com/item?id=28880782

kjeetgill• 5 years ago

Anyone know how far along graalpython is? I'd imagine it should be a suitable, if not superior, replacement with about as much effort right?

didibus• 5 years ago

Benchmarks seeing a 19.4x improvement going to 20 threads, an almost linear speedup. That's pretty amazing, in Java I feel I never manage to achieve linear speedup past a few threads. How are they managing the overhead?

phkahler4• 5 years ago

Amdahl's law? It depends on the code. If you throw 100 cores at half of your code, that part may get 100x faster. But if the other half is single threaded you'll only see overall performance double.

Offpics• 5 years ago

In other words, you probably never saw improvement past few threads, because your sequential code was slow.

pca006132• 5 years ago

What is the memory model for Python after removing the GIL? Will it introduce memory barriers and atomics with different memory ordering?

biglost• 5 years ago

Pyston https://discord.gg/ARQ2WnB8

cybernautique3• 5 years ago

I'm a random commenter with a chip on his shoulder.

<grumble> Please escape Discord links so people don't accidentally click a live one and thereby expose data to Hammer & Chisel, Inc. </grumble>

It's a constant slap-in-the-face how prevalent Discord is in the tech community. Need support with an obscure library? Discord. Want to talk to contributors for a project? Discord.

I honestly don't know why people so greatly prefer Discord to IRC. The interface? Network effects? Whatever it is, Discord and H&C are disgusting, and I pray the tech community finds a way to escape it.

LesZedCB• 5 years ago

the interface and ubiquity, as you noted.

can you fill me in? a couple google searches didn't turn up much.

xbpx• 5 years ago

I'm looking forward to something like the brilliant rayon parallel operations library https://github.com/rayon-rs/rayon

We won't get data race free guarantees but if built into pandas or Vaex we can have a near transparent API.

It'll really open things up for those apps running on 32 core machines. They're out there, I deploy these things frequently (Plotly Dash framework for large Enterprise customers).

mkl95• 5 years ago

Multithreaded performance, on some benchmarks, scales almost linearly with each new thread in the best case—e.g., when using 20 threads, an 18.1× speedup on one benchmark and a 19.8× speedup on another.

Interesting. When I write Python, and I write Python most of the time, I'm not chasing performance. But when it comes to speed, a 18x speedup gets Python up to par with currently much faster languages like Java. At least if you are willing to spam threads like your life depends on it.

OneTimePetes• 5 years ago

I do not understand the significance of this. If i want serious numbercrunch multi-thread performance in python, i execute it on the gpu?

conda install numba & conda install cudatoolkit comes to mind?

And you should data orientated, so all that remains from objects is arrays of structures with the index being the object indicator. Im honestly puzzled about the use-case..

redeyed5• 5 years ago

I don't think it will happen soon.

But what would be nice currently, is to create map reduce API w/o shared data or just readonly data.

Something like ProcessPoolExecutor but instead of spawning new process and pickling input/output data, create threads w/o GIL w/o pickling input/output data.

Python stands to lose its GIL, and gain a lot of speed

Related Stories