A viable solution for Python concurrency • Hacker News Board

Re: A viable solution for Python concurrency

#321

Post by tzs » Sat, Oct 16, 2021, 3:23 PM UTC

MaXtreeM wrote: post #303

Slight off topic but I am curious about using bits in an integer for flags. As the article mentions Gross uses 2 least significat bits for flags and the rest is an integer for reference counting. When someone considers whether to use most significant bits or least significant bits are there any major differences? Is is easier to implement or faster because of processor architectures/instruction sets to use least sign…

> Is is easier to implement or faster because of processor architectures/instruction sets to use least significnt bits or is that just a matter of choice?

I have no idea if this is the reason in this particular in case, but on most architectures if you can fit everything you need to atomically modify together into one word there will be an instruction to do that quickly.

For example many architectures have a compare-and-swap instruction. That generally takes 3 arguments: a memory address, an old value, and a new value. It atomically compares the word at the given address to the old value, and if and only if they are the same writes the new value to the memory address.

Re: A viable solution for Python concurrency

#322

Post by fullstop » Sat, Oct 16, 2021, 3:33 PM UTC

Too wrote: post #312

fullstop wrote: post #28

Earlier quoted context omitted.

I like using it as well, but I've been bit several times by having runtime exceptions completely swallowed.

Let me guess. Using create_task() without await and assuming it will run to completion in the background to trigger some other event? This is almost always the case of async tasks disappearing into the void. After shooting myself in the foot with this one time to many I have a hard rule to never use create_task. Instead make sure every single task ends up in some kind of gather() or wait() awaited from the top level.…

Yes, exactly this scenario.

Re: A viable solution for Python concurrency

#323

Post by rattray » Sat, Oct 16, 2021, 3:39 PM UTC

otterley wrote: post #320

rattray wrote: post #219

Earlier quoted context omitted.

> Python is the tool I pick ... not for highly performant systems Many high-throughput, high-concurrency systems run on Python, famously including Instagram and Pinterest (which see quite a lot of traffic).

Are the performance-critical components of these sites written in Python? That’s the question.

The question at hand is concurrency, not single-threaded performance.

Re: A viable solution for Python concurrency

#324

Post by benreesman » Sat, Oct 16, 2021, 3:55 PM UTC

ajtulloch wrote: post #22

singhrac wrote: post #10

Notably the dev proposing this (Sam Gross aka colesbury) is/was a major PyTorch developer, so someone quite familiar with high performance Python and extensions.

and he's a genius!

Coming from you that’s very high praise legend!

(Tulloch is the best hacker and mathematician I’ve worked with in a 20 year career).

Re: A viable solution for Python concurrency

#325

Post by otterley » Sat, Oct 16, 2021, 3:58 PM UTC

rattray wrote: post #323

otterley wrote: post #320

Earlier quoted context omitted.

Are the performance-critical components of these sites written in Python? That’s the question.

The question at hand is concurrency, not single-threaded performance.

You said "high throughput" though. Your words, not mine :-)

Re: A viable solution for Python concurrency

#326

Post by btown » Sat, Oct 16, 2021, 4:26 PM UTC

sandGorgon wrote: post #263

btown wrote: post #252

Earlier quoted context omitted.

Yep, we use Gunicorn in full gevent mode, tuned to spawn and route to a gevent-patched Django process per core, each of which can handle as many concurrent requests as will fit in (its slice of) RAM. A far cry from the one-request-per-thread days of yore!

you use gunicorn as a reverse proxy - it seems that you are not running Gunicorn to spawn django processes is it ? I'm wondering how would this work in a kubernetes/docker world.

Gunicorn both acts as a reverse proxy and a master process that forks workers - each of which, in our case, loads Django.

https://docs.gunicorn.org/en/stable/design.html

Re: A viable solution for Python concurrency

#327

Post by ledauphin » Sat, Oct 16, 2021, 4:39 PM UTC

Twisol wrote: post #208

ferdowsi wrote: post #203

Earlier quoted context omitted.

That's a fair opinion. Like many academics and data scientists are probably fine with Python as a tool for scripting or as a simple interface language for calling C libraries. But if Python continues as is, it will continue to to lose major enterprise traction as web companies transition to using faster languages for applications and infrastructure. It'll be tough to stave off the negative feedback loop at that point…

I'm not confident that's a bad thing, and I worry that we're judging languages on metrics that only make sense for startups. Does a language need to chase growth? I'm not saying Python shouldn't improve. But, if it comes to it, Python shouldn't cannibalize the niche it filled to do so. That will just spark other languages to fill the niche again.

right or wrong, Python is hardly a niche language at this point. There's really nothing to cannibalize.

Also, making threading better is not necessarily a new feature if done well - it could be mostly transparent to users.

Re: A viable solution for Python concurrency

#328

Post by btown » Sat, Oct 16, 2021, 4:58 PM UTC

ayush--s wrote: post #283

smetj wrote: post #277

Earlier quoted context omitted.

Gevent is the best thing which ever happened within the async world of Python. It's just great to work with. Rock solid. I have high IO production software running for years with gevent as the workhorse, copes with high load, no maintenance, brilliant. Then came Asyncio, which I personally disliked for the simple reason it became so popular that everybody thinks it's necessary to write an asyncio version of their lib…

It's really easy to shoot yourself in the foot by using global mutable variables. How do you guard against those when using gevent in production?

It's actually quite doable in gevent, because you have a guarantee that only one thread will ever be touching those variables ever. You can have 5 or 50 lines of code and be guaranteed that they will operate atomically, read their writes, be immune to interruption, all that good stuff... as long as they don't do any I/O. Of course, the difference from a platform like Node.js or asyncio (where every async/await yield must be explicit all the way down) is that one of your libraries calling `logger.info(...)` might cause I/O, and then cause an implicit yield to the event loop, and break your atomicity without you knowing about it. But if you don't log, and you just work in memory, with code you own or have audited to not do I/O, the sky's the limit. And you almost always want this kind of well-tested, non-logging, high-performance abstraction layer around global mutable state access anyways.

Re: A viable solution for Python concurrency

#329

Post by BeetleB » Sat, Oct 16, 2021, 5:07 PM UTC

snovv_crash wrote: post #282

BeetleB wrote: post #258

Earlier quoted context omitted.

> The entire Python community was in pain over Python 3 for 10 years Sorry, but that's fiction. Yes, lots of projects (still the minority) simply didn't upgrade, but it's not because they tried and failed. It's because they never prioritized it. > Here's a pain story about a 2 to 3 migration though: Consistent with my claim: > Probably less than 1% of projects had serious issues with the migration. We just hear of a…

Lots of things didn't upgrade because their dependencies didn't. And the dependencies had no reason to, because 3.0 didn't offer anything they didn't have before.

Quite a bit before the deadline, pretty much all dependencies had upgraded. Those that hadn't were more or less abandoned projects.

Sure, you could hunt and find some that were still maintained/developed with Python 2 in, say, 2019. But these again will be the tiny minority.

I still stand by my 1% claim. The problems with upgrading have been vastly exaggerated.

Re: A viable solution for Python concurrency

#330

Post by azinman2 » Sat, Oct 16, 2021, 5:14 PM UTC

modeless wrote: post #262

Threads are certainly important, but I have to say that I found the multiprocessing package to work very well. I think a lot of the things people think they need threads for would actually be better with multiprocessing instead. Memory protection is good! Shared memory is still available and explicit sharing of just what you need is better in a lot of ways than implicit sharing of everything. I will be glad if the GI…

If the GIL is fixed, why would you want multiprocessing versus threads? Threads are cheaper to create, easier to communicate between (even if you need to be careful), and simply do different things than what multiprocessing intends (eg easier for blocking I/O on many threads, versus multiprocessing which is really more of a task queue)