←back to thread

Async/Await is finally back in Zig

(charlesfonseca.substack.com)
39 points barddoo | 8 comments | | HN request time: 1.149s | source | bottom
Show context
ajross ◴[] No.45782414[source]
Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debugging inside out code is likewise really high, even if the top-level expression of the loop generator or whatever is clean.

And it's all for, what? A little memory for thread stacks (most of which ends up being a wash because of all the async contexts being tossed around anyway -- those are still stacks and still big!)? Some top-end performance for people chasing C10k numbers in a world that has scaled into datacenters for a decade anyway?

Not worth it. IMHO it's time to put this to bed.

[1] No one in that thread or post has a good summary, but it's "Rust futures consume wakeup events from fair locks that only emit one event, so can deadlock if they aren't currently being selected and will end up waiting for some other event before doing so."

replies(5): >>45782432 #>>45782502 #>>45782558 #>>45782647 #>>45782786 #
amelius ◴[] No.45782432[source]
What is wrong about C++ exceptions?
replies(3): >>45782469 #>>45782488 #>>45782723 #
KerrAvon ◴[] No.45782488[source]
For one thing, they’re expensive and viral. “Zero overhead” implementations don’t take into account the need for unwind tables. For every function/method that might be thrown across. They’re disabled in a lot of production environments for this reason.
replies(2): >>45782913 #>>45783042 #
1. amelius ◴[] No.45782913[source]
But if you explicitly handle exceptions using IF statements then that's overhead too, right?
replies(1): >>45783017 #
2. arbitrandomuser ◴[] No.45783017[source]
yes but i think branch prediction essentialy makes them zero overhead
replies(1): >>45783266 #
3. neonz80 ◴[] No.45783266[source]
That's a different type of overhead than having unwind tables. With exceptions you wouldn't need a branch after each function call at all.
replies(1): >>45783746 #
4. amelius ◴[] No.45783746{3}[source]
But a branch that is (almost) never taken has an overhead close to the overhead of a NOP instruction, which may be negligible on modern architectures.
replies(1): >>45784284 #
5. neonz80 ◴[] No.45784284{4}[source]
The CPU can not remember an infinite number of branches. Also, many branches will increase code size. With exceptions the unwind tables and unwind code can be placed elsewhere and not take up valuable L1 cache.
replies(1): >>45784355 #
6. amelius ◴[] No.45784355{5}[source]
> The CPU can not remember an infinite number of branches.

I suspect a modern CPU has a branch instruction saying "This branch will never be taken except in exceptions, so assume this branch is not taken". But I must admit I haven't seriously looked at assembly language for some time.

(EDIT: yes, modern CPUs including x86 and ARM allow the programmer/compiler to hint if a branch is expected to be taken).

> Also, many branches will increase code size.

I'd like to see some data on that. Of course branches take code size, but how much is that percentage-wise? I suspect not much.

replies(1): >>45784564 #
7. neonz80 ◴[] No.45784564{6}[source]
You should take a look at the presentation I mentioned elsewhere in this thread. You also have to keep in mind that it's not only the branches that use space, but also the error handling code. Code which must be duplicated for every single call to a particular function.
replies(1): >>45784868 #
8. amelius ◴[] No.45784868{7}[source]
Ok, thanks. But that code needs to be loaded into memory only if the branch takes place. Which, for exceptions, will be not often. The main assumption is: optimize for the common case, where exceptions are not the common case.