Async Python is not faster • Hacker News Board

Re: Async Python is not faster

#241

Post by zzzeek » Fri, Jun 12, 2020, 5:40 PM UTC

calpaterson wrote: post #138

zzzeek wrote: post #122

I am SUPER happy someone else is finally looking at this. It is long past time that the reflexive use of asycnio or systems like gevent/eventlet for no other reason than "hand-wavy SPEED" come to an end. That web applications that literally serve just one user at at time are built in Tornado for "speed". (my example for this is the otherwise excellent SnakeViz: https://jiffyclub.github.io/snakeviz/ which IMO should h…

Hi - yes loved your blogpost! Also very tired of the "async magic performance fairy dust" :) It's a difficult myth to dispel and I think the situation in terms of public mindshare is much worse now than it was in 2015. Some very silly claims from the async crowd now have basically widespread credence. I think one of the root causes is that people are sometimes very woolly about how multi-processing works. One of the…

> One of my worries is that right now it feels like everything in Python is being rewritten in asyncio and the balkanisation of the community could well be more problematic than 2 vs 3.

this is exactly why the issue is so concerning for me as well.

Re: Async Python is not faster

#242

Post by joshuamorton » Fri, Jun 12, 2020, 5:42 PM UTC

WoodenChair wrote: post #235

1337shadow wrote: post #137

Earlier quoted context omitted.

Would that work for you ? result = asyncio.run(red(x)) That's calling async function red from non-async code. Not seeing any particular readability issue with that usage neither. If you don't call asyncio.run or await on the result of an async function call, then you get a coroutine for result.

> result = asyncio.run(red(x)) Still much harder to think about/read then result = red(x) We should be finding ways to get to the latter with concurrency. async/await is at best a patchwork compromise until we can do better.

I much prefer the performance implications of my code be explicit than implicit.

Async in this case has less ceremony than threads. But still enough to make thing explicit.

Re: Async Python is not faster

#243

Post by Grimm1 » Fri, Jun 12, 2020, 5:43 PM UTC

throwaway894345 wrote: post #239

Grimm1 wrote: post #224

Earlier quoted context omitted.

I don't know where you're seeing the Another google search shows me Gunicorn, for instance, using high memory on fork isn't exactly uncommon either. Edit: I reworded some stuff up there and tried to make my point more clear.

The interpreter overhead on macos is 7.7mb. I can't speak to gunicorn configuration but it's far from the only game in town.

Totally fair point, my experience with fork type deploys has only been Gunicorn so I'll take this as a challenge to try some others out.

Re: Async Python is not faster

#244

Post by camgunz » Fri, Jun 12, 2020, 5:43 PM UTC

kirkeby wrote: post #237

camgunz wrote: post #194

Earlier quoted context omitted.

> On the web when the bulk of your application code time is waiting on APIs, database queries, external caches or disk I/O it creates a dramatic increase in the capacity of your server if you can do it with minimal RAM overhead. Python doesn't block on I/O.

Of course it does.

It releases the GIL.

Edit: sorry I can do better.

If you're using async/await to not block on I/O while handling a request, you still have to wait for that I/O to finish before you return a response. Async adds overhead because you schedule the coroutine and then resume execution.

The OS is better at scheduling these things because it can do it in kernel space in C. Async/await pushes that scheduling into user space, sometimes in interpreted code. Sometimes you need that, but very often you don't. This is in conflict with "async the world", which effectively bakes that overhead into everything. This explains the lower throughput, higher latency, and higher memory usage.

So effectively this means "run more processes/threads". If you can only have 1 process/thread and cannot afford to block, then yes async is your only option. But again that case is pretty rare.

Re: Async Python is not faster

#245

Post by makz » Fri, Jun 12, 2020, 5:44 PM UTC

Last time I checked async in Python didn’t even work properly, has this changed lately?

Re: Async Python is not faster

#246

Post by joshuamorton » Fri, Jun 12, 2020, 5:45 PM UTC

ghostwriter wrote: post #52

jordic wrote: post #42

Earlier quoted context omitted.

Hiding awaitables from the language, sounds like against the zen (explicit better than implicit) For example, when someone access a descriptor in Django.. this could end being a query to the db (transparent) but dangerous. With asyncio you explicitly await something to return the execution to the event loop. At least for me sounds like a safer behaviour

> Hiding awaitables from the language, sounds like against the zen (explicit better than implicit) Zen is not respected by explicit asyncio, just try to compose asyncio with iterators [1] [1] https://stackoverflow.com/questions/42448664/async-generator... This problem doesn't exist with gevent, and composability is a desired thing in any programming language. Python's asyncio fractioned the community that was previou…

Read that thread in full, it's also a case of explicit is better than implicit. (Async for vs for loops, essentially)

Re: Async Python is not faster

#247

Post by arghwhat » Fri, Jun 12, 2020, 5:48 PM UTC

crimsonalucard1 wrote: post #159

arghwhat wrote: post #110

Earlier quoted context omitted.

>... is not necessarily a performance improvement over a sync version that just starts more workers and has the OS kernel scheduler organise things. This is very true, especially when actual work is involved. Remember, the kernel uses the exact same mechanism to have a process wait on a synchronous read/write, as it does for a processes issuing epoll_wait. Furthermore, isolating tasks into their own processes (or, si…

Yeah except nodejs will beat flask in this same exact benchmark. Explain that.

JIT compiler.

Re: Async Python is not faster

#248

Post by kortex » Fri, Jun 12, 2020, 5:48 PM UTC

How difficult would it be to write a python runtime, let's call it MPython (meta), that forks into separate Python interpreters, 100% orthogonal, except for channels/shm. Could even use separate entry points, but all the same PID. Multiprocessing (iirc) forks from the first python process (this breaks some things depending on when you fork, eg gRPC with torch.dataloader with multiprocessing will crash).

Does that get you anything, or am I misunderstanding how multiprocessing/fork works?

Re: Async Python is not faster

#249

Post by BiteCode_dev » Fri, Jun 12, 2020, 5:51 PM UTC

phodge wrote: post #93

How is this result surprising? The point of coroutines isn't to make your code execute faster, it's to prevent your process sitting idle while it waits for I/O. When you're dealing with external REST APIs that take multiple seconds to respond, then the async version is substantially "faster" because your process can get some other useful work done while it's waiting. Obviously the async framework introduces some over…

This is not what this article is about.

The surprising conclusion of the article is that on a realistic scenario, the async web frameworks will ouput less requests/sec than the sync ones.

I'm very familiar with Python concurrency paradigms, and I wasn't expecting that at all.

Add to that zzzeek's article (the guy wrote SQLA...) stating async is also slower for db access, this makes async less and less appealing, given the additional complexity it adds.

Now appart from doing a crawler, or needing to support websockets, I find hard to justify asyncio. In fact, with David Beasley hinting that you probably can get away with spawning a 1000 threads, it raises more doubts.

The whole point of async was that, at least when dealing with a lot of concurrent I/O, it would be a win compared to threads+multiprocessing. If just by cranking the number of sync workers you get better results for less complexity, this is bad.

Re: Async Python is not faster

#250

Post by arghwhat » Fri, Jun 12, 2020, 5:55 PM UTC

jinglebells wrote: post #211

crimsonalucard1 wrote: post #159

Earlier quoted context omitted.

Yeah except nodejs will beat flask in this same exact benchmark. Explain that.

Nodejs is faster than Python as a general rule, anyway. As I understand, Nodejs compiles Javascript, Python interprets Python code. I do a lot of Django and Nodejs and Django is great to sketch an app out, but I've noticed rewriting endpoints in Nodejs directly accessing postgres gets much better performance. Just my 2c

CPython, the reference implementation, interprets Python. PyPy interprets and JIT compiles Python, and more exotic things like Cython and Grumpy statically compiles Python (often through another, intermediate language like C or Go).

Node.js, using V8, interprets and JIT compiles JavaScript.

Although note that, while Node.js is fast relative to Python, it's still pretty slow. If you're writing web-stuff, I'd recommend Go instead for casually written, good performance.