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

301–310 of 513 posts

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

#301

Post by seanthemon »

usrbinbash wrote: post #277
jmount wrote: post #46

Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.

> Parallelize at the fork level IPC is a PITA, and orchestrating processes is even worse. > or at the isolated numeric library level Not everything I want to parallelise in python runs in numpy. Simple example: WebService Backends. I have a 64 core server running a Werkzeug/Gunicorn application. The Service is mostly doing CPU bound tasks (data aggregation and analysis), so asyncio is pointless. What happens is, it r…

Exactly my thinking, using more cores is exactly your use case and will hopefully make Python superb at large scale data processing with cross-communication.

I think, rightfully, the concern is people who will try to use this incorrectly causing major bloat to CPython.

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

#302

Post by JonChesterfield »

concordDance wrote: post #296
JonChesterfield wrote: post #242

Earlier quoted context omitted.

I hope it'll be lua. I fear it'll be javascript.

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

Lexical scope, first class functions, native coroutines, compiler available at runtime. Trivially extensible. It's semantically really close to lisp. Yep, lua's one of my favourites. The front end syntax isn't what I'd like but whatever, I can still see the AST through it with a little effort.

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

#303

Post by samsquire »

Thank you so much Python core developers and steering council. Python is one of my favourite languages along with Java and C.

I greatly welcome true multithreading in Python.

I use both multiprocessing and multithreading in Python for different projects. See [0] for my multiprocessing example and python Threads for IO heavy tasks in [1]. But it would be far more efficient to use true threads.

Threads can communicate any amount of data in a single atomic almost instant operation. Using the local loopback interface or multiprocessing or pipes, this is not possible.

I am working on a multithreading architecture I call three tier multithreading architecture

https://github.com/samsquire/three-tier-multithreaded-archit...

My goal is extremely scalable and performant servers but Python is probably the wrong job for that.

[0]: https://news.ycombinator.com/item?id=36897054 (my description of my use of multiprocessing) [1]: https://devops-pipeline.com/ (my use of multithreading)

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

#304

Post by usrbinbash »

csmpltn wrote: post #297
usrbinbash wrote: post #279

Earlier quoted context omitted.

> you're already getting free multi-core. Please explain: In what sense is the overhead of starting actual OS processes, and relying on IPC "free", compared to running threads or even greenlets, and using shared process memory?

> In what sense is the overhead of starting actual OS processes, and relying on IPC "free" With Python's current multiprocessing utilities - you get a big discount by not having to write thread-safe code, or worry about synchronization, despite the GIL still being there. Very broadly speaking, it's "free" in the sense that the OS handles parallelism automatically at the process-level, and provides a simple communicat…

> It's "free" in the sense that you don't need to re-write large parts of the VM

In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5

> and teach the entire Python community how to safely write multi-threaded code

People who don't write threaded code don't need to worry about it. And people who write threaded code in python already need to worry about writing thread-safe code. The GIL doesn't prevent race conditions between individual python instructions.

> Python has the means to do that already

And as outlined above, these means are no suitable replacement for true thread based parallelism.

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

#305

Post by Dylan16807 »

insanitybit wrote: post #188
paulddraper wrote: post #166

Earlier quoted context omitted.

It's not nice but it is true. "Dur dur this is just like 2 -> 3." HN had always been susceptible to drive-by ignorant comments, but it's reaching new levels. There's literally nothing of substance to the suggestion. (And if you think there is, present an actual informed argument.)

It wasn't a suggestion, they were asking a question.

Oh please. Even if we ignore that any question can have implications, they directly said "someone has to say it".

They were explicitly suggesting something by asking that question.

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

#306

Post by lozenge »

slt2021 wrote: post #73
n2d4 wrote: post #66

Earlier quoted context omitted.

It's only about performance. asyncio is still inherently single-threaded, and hence also single core. multiprocessing is multi-core and hence better for performance, but each process is relatively heavy and there's additional overhead to shared memory. GIL multi-threading is both single-core and difficult to use correctly. No-GIL multi-threading is multi-core, though difficult to use. I don't know the Python implemen…

I would argue that if you have large concurrency and shared complex state - you better off use kafka and redis/memcached as a shared state - and design proper fan-out. This design scales much better for systems that will eventually overgrow one big machine. the No-GIL pytohn will be of no use, when you need to deploy your app across 100s machines. I understand people want to take advantage of all cores etc, but at la…

PostgreSQL shows how far you can get with a single big box and using multiple cores and shared memory. It's incredibly powerful and the vast majority of applications never have data big enough to warrant "100s of machines".

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

#307

Post by miraculixx »

usrbinbash wrote: post #264
wokwokwok wrote: post #161

Earlier quoted context omitted.

I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”. That’s not whining; it’s just an observation that the committee making these decisions gives zero ducks about the impact this will have for anyone other than the handful of vested parties involved in making the decisions. Pypi h…

First of all, these changes are not being introduced because of a committee. They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python developer community for ages. > “but now I have to rewrite my library because some people might use it in non-GIL mode”. Yes, if library maintainers want their library to remain relevant…

> They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python

Where is this demand exactly? We hear a lot of complaining but very often this is due to a lack of awareness of available (& often better) alternatives to threading.

There is a very small number of use cases that will benefit from free threading.

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

#308

Post by lozenge »

slt2021 wrote: post #268
matsemann wrote: post #212

Earlier quoted context omitted.

Well I don't agree that just because one needs >1 servers, no-gil is suddenly useless. Still lots of complexity and awkwardness that can be avoided if you can do threading instead of processes. Like Promotheus scraping from a non-webserver python app is a pita, as you need a new process and lots of communication, vs just plug and play as in other languages. Or just the insane resource usage. Had a java app serving mu…

It is not fair to compare CPython (which is on purpose not optimized, only a reference implementation of interpretable scripting language without any focus on performance) to OpenJDK - an arguably state of the art compiled bytecode VM with JIT and AOT compilers available, with decades and many $millions poured into runtime/JIT/GC/etc research and optimization

"on purpose not optimized, only a reference implementation of interpretable scripting language without any focus on performance"

That policy is over.

As the last years have shown, no alternative implementation can get off the ground due to C extensions and compatibility concerns, and CPython is now relied on for many large applications. It no longer makes sense to prioritise a simple implementation over performance.

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

#309

Post by pjmlp »

weinzierl wrote: post #293
neilv wrote: post #61

Earlier quoted context omitted.

I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice fea…

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.

Like not everyone toy app isn't going to be the next FAANG, there are plenty of workloads where it hardly matters, while 30 years later it is still a mess in C and C++.

And between C++ and Rust coroutines, still not sure which one I like less.

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

#310

Post by samsquire »

slt2021 wrote: post #54

Naiive question: Who needs No-GIL when we have asyncio and multiprocessing packages ? never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed. is there any use case of No-GIL which is not solved by multiprocessing ? I thought Single threaded execution without overhead for concurrency primitives is the best way to high p…

LMAX Disruptor is multithreaded.

Multithreading is more efficient but more difficult to work with.

You share the same address space in threads, so you can communicate any amount of data between threads instantly within a lock. The same cannot be said for network traffic or OS pipes or multiprocessing.

Multiprocessing uses pickle to serialize your data and deserialize it in the other python interpreter.

If you start a Python Thread, you're still single threaded due to the GIL.

Post reply on HN