Hacker News Reader

Comment by claudiojulio | Hacker News Reader

I don't understand, actix-web uses async / await and is ultra fast. https://www.techempower.com/benchmarks/

Does this have to do with the Tokio runtime that more efficiently coordinates the asynchronous code?

Automatically translated.

I'd expect any python codebase which tries to use async/await based co-operative multi-tasking for concurrency at a larger scale would inevitably run into long-tail latency walls -- not just once but repeatedly as the codebase grows/changes.

The potential for a code change or addition to produce unexpected synchronous blocking (potentially with GIL held) _somewhere_ seems really high and I have to imagine it would be very hard to avoid in the context of a real application codebase ...

You would have the same problem in Rust/Tokio and many other languages. The compiler is not able to know which calls could block. Suppose you have this async state machine server on a single thread, super fast, but somewhere it opens a file synchronously, let's say on a network mount to make things worse. No way a purely static VM-free language can help against that. Go (see: goroutines) is able to automatically suspend at those points and continue execution elsewhere. It comes with a big runtime but you get what you pay for.

What's Go going to do if some ffi library written in C does a synchronous syscall? It's in the same situation.

Go discourages C FFI but it runs those in kernel threads just to be safe. If you are using a lot of C FFI calls that all block, then it could be a problem (all cores are blocked).

Yes, but there’s nothing akin to the GIL in Rust/Tokio, so the potential impact of blocking is lower, and you can use spawn_blocking to move any blocking code (that you cannot eliminate) off the main worker threads that are polling futures, or use other techniques like run the blocking work on another standard thread and await on a channel for the result.

I would take this benchmark with a huge grain of salt: https://64.github.io/actix/#blazingly-fast-or-not

I think the area is a lot more complex than the relative latency and throughput of synchronous vs async. For the observations in the environments of Ruby and Python, I think the observations feel true, but switching out to different sections of processing to different technologies I suspect different generalizations would have to be made.

Someone please correct me if I'm wrong, but Rust async/await isn't implemented with green threads, but with OS threads. Those can be pre-empted.

Async/await does not use threads of any kind. It creates a state machine.

Executors may execute those state machines on a single thread, or map them to many threads. The latter looks kinda like green threads depending on what your definition of “green thread” is.

nothing about how it works is built into the language, its up to user code/libraries to decide how to do it.

the popular libraries like tokio are using something akin to green threads, though people picky about definitions may not agree to that nomenclature.

> nothing about how it works is built into the language

I think the state machine required to yield, async & await is baked into the language.

But yes, one can implement the Future trait to take finer control.

It's single threaded and completely userspace. Rust async/await is a fancy way to write poll/epoll. It can limit the amount of time your program is blocked on IO (insofar as the implementation is as you would expect it (not guaranteed by the language)), but it will not do parallelism. For example you wouldn't async/await a prime number calculation--you'd have to use OS threads.

It’s not necessarily single threaded; Rust async runtimes typically schedule tasks on a pool of multiple OS threads, usually one thread per CPU core. In other words, it can be seen as a form of M:N threading.

Regarding the parent’s question, tasks cannot be preempted from their threads. Threads can of course be preempted from their CPU cores by the OS, but if the number of threads equals the number of cores, this will only happen if other processes on the system are competing for CPU time.

Reply on news.ycombinator.com