Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intent to approve PEP 703: making the GIL optional

discuss.python.org

Post reply on HN
Print view View original

471–480 of 513 posts

Re: Intent to approve PEP 703: making the GIL optional

#471

Post by imtringued »

erinaceousjones wrote: post #462
cutler wrote: post #455

Earlier quoted context omitted.

I never really understood Meta/Facebook's practice of relying on scripting languages. Ok, replacing PHP might not have been an option given the accelerated growth of Facebook but Python was only used for tooling originally, as I understand. If they needed threading and performance so badly why didn't they go for a compilted, statically-typed language?

Sunk cost / laziness - I remember when Facebook wrote their own JIT VM to run PHP on top of (HHVM?) to speed up all that PHP code. Probably was easier to have one crack team of software developers write something new which could interpret all of the existing codebase, than it was to lead a widespread conversion of all of that code into faster languages. ie. not everyone's a senior dev. There's reams more junior devs…

I honestly don't understand why people complain about this. One of the best parts of software development is that your tools keep getting better. Your value as a developer keeps growing because the code you have written in the past gets automatic improvements.

Re: Intent to approve PEP 703: making the GIL optional

#472

Post by hinkley »

qbasic_forever wrote: post #184
hinkley wrote: post #179

Earlier quoted context omitted.

Does Python have a lot of secondary dependencies? I could see someone pulling in two dependencies, not realize they both use the same unsafe library, and end up having them step all over each other.

It does, so much so things like virtualenv were introduced so every program can have its own set of dependencies such that they won't clash with other libs on your system. Something like flask or fastapi pull in a lot of secondary dependencies alone.

Probably doesn't work with FFI though? I'm trying to get a sense of how hypothetical versus very real this problem is.

Re: Intent to approve PEP 703: making the GIL optional

#473

Post by miraculixx »

usrbinbash wrote: post #370
miraculixx wrote: post #333

Earlier quoted context omitted.

You would be well served with arena based (shared) object allocation and a gil per thread model. No need to draw everyone else into this.

> No need to draw everyone else into this Please explain who exactly is "drawn into this"? If you want to use async, this change doesn't affect your code. If you want to use multiprocessing, this change doesn't affect your code. Even if you already use threading, and do it correctly, this change doesn't actually affect your code. So who is "drawn into this"? And please don't say library developers. a) Having to updat…

There will be 5+ years of parallel gil/nogil builds. Every library developer will have to deal with this at some point.

Re: Intent to approve PEP 703: making the GIL optional

#474

Post by concordDance »

DonHopkins wrote: post #394
concordDance wrote: post #296

Earlier quoted context omitted.

Lua? Really? That's by far the most unpleasant language I've coded in.

Obviously there are a LOT of languages you've never coded in.

Yes, I've never coded in brainfuck. But of the languages people actually use its been the most painful.

Re: Intent to approve PEP 703: making the GIL optional

#475

Post by miraculixx »

r0l1 wrote: post #376
miraculixx wrote: post #346

Earlier quoted context omitted.

This requirement could have been well served with a gil per thread and arena based (shared) object allocation model. Every other use case would have been unaffected. Now we change the world for everyone and put most of library developers through a valley of desperation for 5 years+, just so that a very few narrow use cases get the benefits they want. Not a smart move IMHO.

Good point. Did the Meta and Deepmind devs really miss this? I try to avoid python as much as possible, because I mainly work with Go & C++ and multi-threading with those languages is just better (imho). Bringing python a step forward and making it future proof might be a good thing... Even if this means to break some things? Not sure if dismissing the GIL is the right step, but there is a big performance gap to fix.…

The PEP notes subinterpreters as an alternative and says it can be considered a valid approach to achieve paralleism. However it does not discuss why nogil was given preferences. I guess that's ok because the PEP is about nogil.

I'm not sure whether the SC has considered alternative approaches but it would be surprising if not

Re: Intent to approve PEP 703: making the GIL optional

#476

Post by kzrdude »

Phil_Latio wrote: post #99
miraculixx wrote: post #59

Earlier quoted context omitted.

> It's simply not "sane multithreading" not being able to run Python (byte)code concurrentltly Please read my post again. I am advocating a GIL per-thread model with an explicit feature for sharing selected objects. This allows for all cores concurrency, essentially like free threading yet with safeguards. I like to call that a sane way because it builds on decades of research and industry experience of the software…

> I am advocating a GIL per-thread model with an explicit feature for sharing selected objects Is there a PEP or something written about it? I don't like this idea at first glance. Feels like another hack. Though I have to admit it sounds better than the annoying multiprocessing approach. > It's not optional if you build tools and libraries that need be able to run with both gil and no-gil. Why do they need to? A lib…

It's basically becoming reality already, PEP 684 per-interpreter gil is the required structure for this (coming in Python 3.12), then only the interface on top of that remains to be exposed, see WIP like https://github.com/jsbueno/extrainterpreters The full interface to separately-locked interpreter threads is coming in , independent of PEP 703 work.

Re: Intent to approve PEP 703: making the GIL optional

#477

Post by kzrdude »

miraculixx wrote: post #16

Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though you…

I want to agree with you. My hope is that PEP 703 can lead to better implementations of even your safe / structured concurrency model. It will after all still be possible to use, it just won't unfortunately be the only option.

Just like you can today spawn threading.Threads one by one in python, or just map a bunch of function calls over a threadpool using concurrent.futures thread pool.

Re: Intent to approve PEP 703: making the GIL optional

#478

Post by erinaceousjones »

cutler wrote: post #468
erinaceousjones wrote: post #462

Earlier quoted context omitted.

Sunk cost / laziness - I remember when Facebook wrote their own JIT VM to run PHP on top of (HHVM?) to speed up all that PHP code. Probably was easier to have one crack team of software developers write something new which could interpret all of the existing codebase, than it was to lead a widespread conversion of all of that code into faster languages. ie. not everyone's a senior dev. There's reams more junior devs…

Java isn't a scripting language. I don't get your point about junior devs either as FAANG companies such as Facebook can pick and choose from the highest caliber developers.

I conceptually think of Java in the same family of languages as the "scripting" languages as it still (in its default distributions) is a garbage-collected language running on top of a virtual machine instruction set, and allows you to do stuff with dynamic typing / duck-typing and reflection at runtime that less experienced developers (me, as a CS undergrad) can make use of. Compared to stricter typed compiled languages that less experienced devlopers (me, as a CS postgrad) had an inevitable learning curve with. It was slower than it used to be, over time it has had improvements to the language which have introduced progressive increases in performance but also introduced backwards incompatabilities.

RE "scripting" vs "compiled" - I'm probably using the semantics wrong :p

To me, "scripting" is more like... Rexxx, or Lua, or Bash. Stuff that's turing complete but more restricted in how you can express things in the code, or sandboxed (designed to be embedded). Python may have started off designed to be embedded as a scripting language, but these days it's a very very general purpose _predominantly interpreted_ language, considering where it's used and the libraries it has. It's not just used inside of Blender or OpenResty for example.

I'd argue the same about Perl and PHP. If people (psychopaths) are content with using PHP-Gtk to make _desktop_ apps, does it count as scripting language the same way "Lua embedded as a way to make Source Engine entities interactive" is a scripting language? :p

> FAANG companies such as Facebook can pick and choose from the highest caliber developers.

Sure - they have lots of money. They're also very, very big companies, with offices all over the world. Look at the sheer amount of people they hired which they backtracked on later "oops, we hired too many of you, haha, sorry! layoff time!". It doesn't take 10+ years of experience to come fresh from a coding bootcamp, complete the Google code test and become a Noogler in the "Wear OS performance metrics" team writing boilerplate AsyncTasks that call UrlRequests all day every day. Plus on the positive side they encourage people to join through undergrad / new grad schemes. Like, isn't there a whole thing about people _starting_ their tech careers in FAANG corps?

Re: Intent to approve PEP 703: making the GIL optional

#479

Post by imtringued »

tgv wrote: post #388
fred123 wrote: post #233

Earlier quoted context omitted.

Why? On AWS you can rent a 24 TB, 500 core machine. Almost all problems are smaller than that so don’t need to scale to more than one machine. Building applications that run on multiple machines is at least one order of magnitude more complex and thus slower (in development velocity), so needlessly building an application to work distributedly is just bad engineering.

Dear Lord, is that real? It surely would not be appropriate to compensate for bad performance in a Python app.

I wonder if SAP Hana is written in python. Because EC2 Nitro is certified for SAP.

Re: Intent to approve PEP 703: making the GIL optional

#480

Post by weinzierl »

cutler wrote: post #454
weinzierl wrote: post #293

Earlier quoted context omitted.

That Java had concurrency built in from the start is a blessing mostly, but also a bit of a curse. Most of the Java ecosystem is still in the mindset that threads are cheap and firing up a couple more cannot hurt. So we end up with apps that run thousands of threads and this disease is hard to contain.

Green threads are coming to Java this September so all this will be moot.

I wish, but I'm skeptical. It's not that we don't already have the means to be reasonable with threads. The issue in my opinion is more a mixture of path dependency and a mindset that changes too slowly.
Post reply on HN