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

What's up, Python? The GIL removed, a new compiler, optparse deprecated

bitecode.dev

Post reply on HN
Print view View original

171–180 of 302 posts

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#171

Post by iknownothow »

wmwmwm wrote: post #14

Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Every time I’ve done a quick implementation in Python of a service that then became popular (within a firm, so 100s or 1000s of clients) I’ve often ended up having to rewrite in Java so I can throw more threads at servicing the requests (often CPU heavy). I may have missed somethin…

I would consider the following optimizations first before attempting to rewrite an HTTP API since you already did the hard part:

1. For multiples processes use `gunicorn` [1]. Runs your app across multiple processes without you having to touch your code much. It's the same as having the n instances of the same backend app where n being the number of CPU cores you're willing to throw at it. One backend process per core, full isolation.

2. For multiple threads use `gunicorn` + `gevent` workers [2]. Provides multiprocessing + multithreaded functionality out of the box if you have IO intensive. It's not perfect but works very well in some situations.

3. Lastly, if CPU is where you have a bottleneck, that means you have some memory to spare (even if it's not much). Throw some LRU cache or cachetools [3] over functions that return the same result or functions that do expensive I/O.

[1]: https://www.joelsleppy.com/blog/gunicorn-sync-workers/

[2]: https://www.joelsleppy.com/blog/gunicorn-async-workers-with-...

[3]: https://pypi.org/project/cachetools/

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#172

Post by dotnet00 »

Waterluvian wrote: post #32
wmwmwm wrote: post #14

Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Every time I’ve done a quick implementation in Python of a service that then became popular (within a firm, so 100s or 1000s of clients) I’ve often ended up having to rewrite in Java so I can throw more threads at servicing the requests (often CPU heavy). I may have missed somethin…

No, that’s about right. The response, which isn’t technically wrong, is “unless you’re CPU bound, your application should be parallized with a WSGI. You shouldn’t be loading all that up in memory so it shouldn’t matter that you run 5 Python processes that each handle many many concurrent I/O bound requests.” And this is kinda true… I’ve done it a lot. But it’s very inflexible. I hate programming architectures/pattern…

Yes, this is even more the case in languages that are popular with more "applied" programming audiences, like scientific computing. Telling them "no you should be using this complicated DBMS" (or whatever other acronym) is not productive.

It tends to get them exceptionally mad because their concern isn't the ideal way to write the code and architect the system, they simply want to write just enough code to continue their research, and even if they did care about proper architecture, they don't have the time or interest in learning/testing a new library for every little thing. They'd rather be putting that time reading up on their field of research.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#173

Post by imtringued »

chlorion wrote: post #119
alfalfasprout wrote: post #93

Earlier quoted context omitted.

Nowadays multiprocessing is rarely the answer. Between all the gotchas (memory usage can be horrific, have to be careful what you modify, etc.) it's almost never the right answer. Nowadays numba is usually a better solution for when you want to run some computationally expensive python code that itself calls numpy, etc. For the parent commenter's use case though that wouldn't be a great solution either. In general, P…

You have to be much more careful about what you modify when using multithreading, so I'm not sure what you mean by that. A lot of people here mention that sharing data is much easier with multithreading, but doing this without races is not easy. You can't just use the values from difference threads like you would in normal code, you need to synchronize access with locks, which can be difficult to do correctly and can…

[flagged]

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#174

Post by sideeffffect »

oivey wrote: post #26
csmpltn wrote: post #17

Earlier quoted context omitted.

There are plenty of other Python VMs that don't have a GIL and can be used already today, out of the box (examples include Jython and IronPython). Despite that fact - CPython remains the most popular Python VM out there (it utilizes a GIL). Instead of waiting for the GIL to be removed out of CPython - take your fancy Python code and just run it using a different VM. It's literally as simple as that. If the GIL was su…

People stay on CPython due to the performance of C extensions and the vast ecosystem based on them. The fact that people have stuck with CPython isn't at all evidence that they like the GIL or that it doesn't lead to significant technical problems. Besides the C extension issue, Jython is based on Python 2.7 and IronPython appears to be on 3.4. These aren't serious alternatives.

Not true. They're is GraalPython, which is for Python 3 and supports also native code extensions.

https://github.com/oracle/graalpython

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#175

Post by wiseowise »

empthought wrote: post #152
KolenCh wrote: post #138

Earlier quoted context omitted.

Why do you think it would help? It provides a nice interface but is using multiprocessing or multi threading under the hood depending on which executioner you use: > The ProcessPoolExecutor class is an Executor subclass that uses a pool of processes to execute calls asynchronously. ProcessPoolExecutor uses the multiprocessing module, which allows it to side-step the Global Interpreter Lock but also means that only pi…

Your trouble seems to involve not understanding how to set up signal handlers, which ProcessPoolExecutor handles for you and exposes via a BrokenProcessPool exception.

> Derived from BrokenExecutor (formerly RuntimeError), this exception class is raised when one of the workers of a ProcessPoolExecutor has terminated in a non-clean fashion (for example, if it was killed from the outside).

What if it hangs?

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#176

Post by antupis »

BiteCode_dev wrote: post #169
wodenokoto wrote: post #140

When it was an in dev project, I felt the consensus on HN was that it was amazing work and a shame that it looked like the steering committee wouldn’t adopt it. Now they have and everyone seems to hate it.

It's the eternal pendulum: - take no risk, and people will blame the project for being static. - take risks, and people will blame the project for being reckless. E.G: - don't adopt a new feature, and your language is old, becoming irrelevant, and a wave of comments will tell you how they just can't use it for X because they don't have it. - break compat, and you will have a horde stating you don't care about users t…

World would need one more language which would have very barebone core something like very minimal go or python but strong metaprogramming features so you could expand language if you need.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#177

Post by moonshinefe »

nickcw wrote: post #74
cvnmalk wrote: post #28

Which, except for optparse, was all on the front page yesterday. So optparse is deprecated. More work I guess apart from auditing extensions for threading. Life is great in the Python treadmill.

I've tried to love argparse but it is so complicated. I always have to read the docs each time I use it. getopt has its own brutal simplicity.

If you aren't averse to using a third party package, on my personal projects I always found https://github.com/docopt/docopt to be nice.

You can kill 2 birds with one stone by documenting your scripts while also providing the argument structure / parsing.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#178

Post by IshKebab »

xcv123 wrote: post #149
mypalmike wrote: post #113

Earlier quoted context omitted.

Not sure why you mention "thread pool executor", which of course does not get you concurrency due to the gil.

Pedantic nerd nitpick: it gives you concurrency but not parallelism. (Concurrent threads can be time sliced on one core)

It was clear from the context that he meant concurrently running not concurrently in progress. I wish nerds would give up on this parallelism/concurrency pedantry or at least choose some new nomenclature that didn't conflict so massively with the English meaning of "concurrent".

I mean it's not even right. Most parallel/concurrent pedants would consider multithreaded code to be "parallel" even if it is running on a single core.

I think the best thing is to talk about threads, because then you can distinguish e.g. OS threads and hardware threads.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#180

Post by ghshephard »

imtringued wrote: post #173
chlorion wrote: post #119

Earlier quoted context omitted.

You have to be much more careful about what you modify when using multithreading, so I'm not sure what you mean by that. A lot of people here mention that sharing data is much easier with multithreading, but doing this without races is not easy. You can't just use the values from difference threads like you would in normal code, you need to synchronize access with locks, which can be difficult to do correctly and can…

[flagged]

https://news.ycombinator.com/newsguidelines.html

> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

Post reply on HN