3 ms·

> A function is still "async" (albeit pointlessly so) even if it doesn't yield. No that's not correct: https://godbolt.org/z/5AMxy- https://godbolt.org/z/5AMx

> A function is still "async" (albeit pointlessly so) even if it doesn't yield. No that's not correct: https://godbolt.org/z/5AMxy- https://godbolt.org/z/5AMxy-

yellowapple 6y ago
I feel like that demonstrates my point (though maybe I didn't communicate it well). Given a modified version of that example¹, with everything being apples-to-apples (identical input code minus the presence of async/await keywords, and sticking to a debug build instead of --release-fast so as to avoid Zig and/or LLVM optimizing away the semantic differences), there are subtle differences in the interaction between the generated 'add' and 'add2' (calling convention differences maybe? I strongly suspect you'd know more about what's going on with rax and rcx there...). These differences continue to be visible with --release-safe (though --release-fast and --release-small both optimize away those differences, which does indeed seem like a reasonable thing to do). That is: even in that example, the fact that add2() doesn't yield doesn't change the fact that Zig treats it differently (namely, I would guess, by assuming that it has the potential to yield and thus doing the necessary bookkeeping to handle that) depending on whether or not it's invoked as an async function. If async/await were indeed "no-ops" as the article asserts, then shouldn't the assembly outputs here be identical in debug and release-safe? The LLVM IR output for --release-safe is telling, too, since it's apparent that Zig's emitting IR specifically around an async frame (at least that's my impression from seeing all those getelementptrs on a @Frame(add2) -- which, come to think of it, do correspond to the extra rax/rcx manipulations in the async version). --release-fast even shows a difference on the IR level, though it's admittedly pretty inconsequential-looking (just an extra @llvm.debug.value call in the non-async version). EDIT: as another interesting note, these differences persist even with --single-threaded, which contradicts the documentation on Single Threaded Builds (which states that "The overhead of Async Functions becomes equivalent to function call overhead." -- I mean, I guess that's true with --release-fast or --release-small, but --single-threaded doesn't seem to have an effect there). ---- ¹: https://godbolt.org/z/_zfkeJ https://godbolt.org/z/_zfkeJ
- AndyKelley 6y ago
  Note that in your updated example, `add2` has the exact same machine code in all build configurations. It's the calling code that is different - it has some easily-optimizable shims that allow passing the frame type to another function which expects such a type. You have a misleading variable name there: var frame = add2(a, b); return frame; It's not a "frame", it's just the i32 result of adding 2 numbers. This should be changed to: return add2(a, b); Or if you wanted to be very explicit: const result: i32 = add2(a, b); return result; The only thing I wanted to point out in the grandparent is that a function is async if and only if it yields. You can see from your godbolt example that `add2` is the same machine code in both code examples, because it does not yield.
  - yellowapple 6y ago
    > You can see from your godbolt example that `add2` is the same machine code in both code examples, because it does not yield. Right, but ain't that the point: that Zig functions themselves are neither sync nor async (they're "colorblind"), but rather it's just how they're called? I mean, I guess one way to "color" the function would be to have it suspend or do something with @frame() (more on that below...), but that (from what I'm seeing) only forces functions to be async, and doesn't seem to imply a function without that to not (potentially) be async. That is: the fact that the calling code is what's different is exactly my point. Nothing the function itself is doing is (I'd argue) what dictates whether or not it's "sync" or "async"; it's purely whether or not the caller is invoking it synchronously or asynchronously. Hence: a function can still be "async" even if it never yields. I think we just have different ideas of what "async" means (i.e. whether it's a property of the caller or callee); I'm arguing the former, for the same reason that I'd argue a function (or more precisely its invocation) to be "comptime" if it's executed within a comptime {...} block, regardless of whether or not the function itself is aware of this. Even excluding this particular angle, though (i.e. going with the convention of asyncness being callee-dependent), the docs have a couple¹ examples² of situations where an "async" function in Zig seemingly won't yield (due to a suspend that immediately resumes itself or due to simply invoking @frame without doing anything with it, respectively), and indeed both cases do appear to produce code¹ consistent with said cases not yielding (I certainly ain't resuming/awaiting anything in add(), and yet the return value is 3 as expected in either case, as opposed to 0⁴ if there's an actual yield before the arithmetic happens). ---- ¹: https://ziglang.org/documentation/master/#Resuming-from-Suspend-Blocks https://ziglang.org/documentation/master/#Resuming-from-Susp... ²: https://ziglang.org/documentation/master/#frame https://ziglang.org/documentation/master/#frame ³: https://godbolt.org/z/kby4vB https://godbolt.org/z/kby4vB ⁴: Tangent: I'd expect returning or otherwise trying to read an undefined value would produce a panic, yeah? Yet, in both debug and release-safe returning "result" from main() while it's set to "undefined" results in a 0 return value. Ain't sure if this is a bug or expected behavior.

> A function is still "async" (albeit pointlessly so) even if it doesn't yield. No that's not correct: https://godbolt.org/z/5AMxy- https://godbolt.org/z/5AMxy-

yellowapple 6y ago

I feel like that demonstrates my point (though maybe I didn't communicate it well). Given a modified version of that example¹, with everything being apples-to-apples (identical input code minus the presence of async/await keywords, and sticking to a debug build instead of --release-fast so as to avoid Zig and/or LLVM optimizing away the semantic differences), there are subtle differences in the interaction between the generated 'add' and 'add2' (calling convention differences maybe? I strongly suspect you'd know more about what's going on with rax and rcx there...). These differences continue to be visible with --release-safe (though --release-fast and --release-small both optimize away those differences, which does indeed seem like a reasonable thing to do). That is: even in that example, the fact that add2() doesn't yield doesn't change the fact that Zig treats it differently (namely, I would guess, by assuming that it has the potential to yield and thus doing the necessary bookkeeping to handle that) depending on whether or not it's invoked as an async function. If async/await were indeed "no-ops" as the article asserts, then shouldn't the assembly outputs here be identical in debug and release-safe? The LLVM IR output for --release-safe is telling, too, since it's apparent that Zig's emitting IR specifically around an async frame (at least that's my impression from seeing all those getelementptrs on a @Frame(add2) -- which, come to think of it, do correspond to the extra rax/rcx manipulations in the async version). --release-fast even shows a difference on the IR level, though it's admittedly pretty inconsequential-looking (just an extra @llvm.debug.value call in the non-async version). EDIT: as another interesting note, these differences persist even with --single-threaded, which contradicts the documentation on Single Threaded Builds (which states that "The overhead of Async Functions becomes equivalent to function call overhead." -- I mean, I guess that's true with --release-fast or --release-small, but --single-threaded doesn't seem to have an effect there). ---- ¹: https://godbolt.org/z/_zfkeJ https://godbolt.org/z/_zfkeJ

AndyKelley 6y ago
Note that in your updated example, `add2` has the exact same machine code in all build configurations. It's the calling code that is different - it has some easily-optimizable shims that allow passing the frame type to another function which expects such a type. You have a misleading variable name there: var frame = add2(a, b); return frame; It's not a "frame", it's just the i32 result of adding 2 numbers. This should be changed to: return add2(a, b); Or if you wanted to be very explicit: const result: i32 = add2(a, b); return result; The only thing I wanted to point out in the grandparent is that a function is async if and only if it yields. You can see from your godbolt example that `add2` is the same machine code in both code examples, because it does not yield.
- yellowapple 6y ago
  > You can see from your godbolt example that `add2` is the same machine code in both code examples, because it does not yield. Right, but ain't that the point: that Zig functions themselves are neither sync nor async (they're "colorblind"), but rather it's just how they're called? I mean, I guess one way to "color" the function would be to have it suspend or do something with @frame() (more on that below...), but that (from what I'm seeing) only forces functions to be async, and doesn't seem to imply a function without that to not (potentially) be async. That is: the fact that the calling code is what's different is exactly my point. Nothing the function itself is doing is (I'd argue) what dictates whether or not it's "sync" or "async"; it's purely whether or not the caller is invoking it synchronously or asynchronously. Hence: a function can still be "async" even if it never yields. I think we just have different ideas of what "async" means (i.e. whether it's a property of the caller or callee); I'm arguing the former, for the same reason that I'd argue a function (or more precisely its invocation) to be "comptime" if it's executed within a comptime {...} block, regardless of whether or not the function itself is aware of this. Even excluding this particular angle, though (i.e. going with the convention of asyncness being callee-dependent), the docs have a couple¹ examples² of situations where an "async" function in Zig seemingly won't yield (due to a suspend that immediately resumes itself or due to simply invoking @frame without doing anything with it, respectively), and indeed both cases do appear to produce code¹ consistent with said cases not yielding (I certainly ain't resuming/awaiting anything in add(), and yet the return value is 3 as expected in either case, as opposed to 0⁴ if there's an actual yield before the arithmetic happens). ---- ¹: https://ziglang.org/documentation/master/#Resuming-from-Suspend-Blocks https://ziglang.org/documentation/master/#Resuming-from-Susp... ²: https://ziglang.org/documentation/master/#frame https://ziglang.org/documentation/master/#frame ³: https://godbolt.org/z/kby4vB https://godbolt.org/z/kby4vB ⁴: Tangent: I'd expect returning or otherwise trying to read an undefined value would produce a panic, yeah? Yet, in both debug and release-safe returning "result" from main() while it's set to "undefined" results in a 0 return value. Ain't sure if this is a bug or expected behavior.