upvote

points

by swiftcoder5 hours ago |
comments
upvoteby groundzeros20155 hours ago|
[-]
In that sentence I’m referring to the abstract idea of a thread of execution as a model of programming, not OS threads. A green thread implementation could do it too.

But what you said about kernel implementation is true. But are we really saying that the primary motivation for async/await is performance? How many programmers would give that answer? How many programs are actually hitting that bottleneck?

Doesn’t that buck the trend of every other language development in the past 20 years, emphasizing correctness and expressively over raw performance?

reply
upvoteby nchie4 hours ago|
parent|
next
[-]
> But are we really saying that the primary motivation for async/await is performance?

Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?

reply
upvoteby groundzeros20154 hours ago|
parent|
next
[-]
I agree. Managing many http requests or responses was a motivating problem.

What I question is whether 1. Most programs resemble that, so that they make it an invasive feature of every general purpose language. 2. Whether programmers are making a conscious choice because they ruled out the perf overhead of the simpler model we have by default.

reply
upvoteby swiftcoder4 hours ago|
parent|
[-]
That is why we have the function colouring problem and a split ecosystem in the first place - if it were obviously better in all cases, we'd make async the default, and get rid of the split altogether (and there are languages, like Erlang, that fall on this side of the fence)
reply
upvoteby lukaslalinsky1 hours ago|
parent|
prev|
[-]
It was not for performance reasons, but for scaling up.
reply
upvoteby pjc501 hours ago|
parent|
[-]
That's the same thing?
reply
upvoteby swiftcoder5 hours ago|
parent|
prev|
next
[-]
> But are we really saying that the primary motivation for async/await is performance?

The original motivation for not using OS threads was indeed performance. Async/await is mostly syntax sugar to fix some of the ergonomic problems of writing continuation-based code (Rust more or less skipped the intermediate "callback hell" with futures that Javascript/Python et al suffered through).

reply
upvoteby PunchyHamster3 hours ago|
parent|
[-]
In some languages, yes, in others (js/python) async is just workaround about not having proper threading.
reply
upvoteby swiftcoder1 hours ago|
parent|
[-]
Python used multiple threads to handle I/O long before async/await was a glimmer in anyone's mind (despite the GIL). nodejs is one of the very few languages I can think of that was born single-threaded and used an asynchronous runtime from the get-go
reply
upvoteby sureglymop4 hours ago|
parent|
prev|
[-]
Importantly though, performance might be worse depending on use case and program. Specifically with scheduling in user space it can negatively impact branch prediction as your CPU is already hyper optimized for doing things differently.

It's all nuanced and what to choose requires careful evaluation.

reply