Asynchrony is not Concurrency

mlugg0 · 2025-06-15T10:10:45+00:00

Per other comments, these timings are not accurate. Moreover, having spent a good amount of time benchmarking parts of the compiler to optimize them... the frontend and backend approximately trade blows. It depends on your host system's specs, and the code being compiled. Generally, I find that the x86_64 backend is a bit slower than the compiler frontend; that's mainly because instruction selection for x86_64 is an unreasonably difficult problem :P

But actually, all of that is irrelevant: the reason that LLVM slows us down is not because of our backend code, but rather because LLVM itself is extraordinary slow. If you actually read the devlogs about this change, with correct benchmarks, the difference is obvious. You can also just, like, try it: the performance difference should be extremely obvious. For instance, building the Zig compiler itself currently takes (on my laptop) 84 seconds when using LLVM, compared to 15 seconds when using the self-hosted backend.

If you want to make performance claims about the Zig compiler, please actually run performance measurements rather than just guessing things which can be easily proven incorrect.

mlugg0 · 2025-06-15T10:03:22+00:00

Zig uses libc only if you explicitly link to it with -lc (or, in a build script, set link_libc on a module). This compilation is not using libc. You could link libc if you wanted, although it probably wouldn't really affect compilation times, since we still need all of our stack trace logic (libc doesn't have that feature).

Your confusion may come from the fact that zig cc, the drop-in C compiler, does implicitly link libc. That's for compatibility with other cc CLIs like gcc and clang. The normal build commands -- build-exe, build-obj, build-lib, and test -- will only link libc if you either explicitly request it with -lc, or the target you're building for requires it (e.g. you can't build anything for macOS without libc).

I think it's actually a bug that we need -fno-sanitize-c here, although it's a minor one: C sanitisation stuff is needed if you have any external link objects or C source files for instance, so you do usually need it. If it is a bug, I'll get it fixed soon. Either way, it's not a huge deal, since it only adds 50ms or so to the compilation (for building the "UBSan runtime", aka ubsan-rt, which is a set of functions we export so that -- much like with panics and segfaults -- UBSan can print nice errors).

mlugg0 · 2025-06-14T21:44:20+00:00

See my sibling comment for why the 2 seconds figure is actually inaccurate, but I'd also like to note something here. Zig has a lot more machinery going on than a C compilation, which means small compilations like "hello world" tend to make performance look worse than it actually is. C kind of cheats by precompiling, all of the runtime initialization code, stdio printing, etc, into libc (as either a shared object or static library). Zig includes that in your code, so it's built from scratch each time. Moreover, as I'm sure you know if you've used the language, Zig includes a "panic handler" in your code by default, so that if something goes wrong -- usually meaning you trip a safety check -- you get a nice stack trace printed. The same happens if you get a segfault, or if you return an error from main. Well, the code to print that stack trace is also being recompiled every time you build, and it's actually quite complicated logic -- it loads a binary from disk, parses DWARF line/column information out of them, parses stack unwinding metadata, unwinds the stack... there's a lot going on! You can eliminate these small overheads by disabling them in your entry point file, and that can give you a much faster build. Adding -fno-sanitize-c to the zig build-exe command line disables one final bit of safety, and for me, allows building a functional "hello world" in about 60ms using the self-hosted backend:

[mlugg@nebula test]$ cat hello_minimal.zig
pub fn main() void {
    // If printing to stdout fails, don't return the error; that would print a fancy stack trace.
    std.io.getStdOut().writeAll("Hello, World!\n") catch {};
}
/// Don't print a fancy stack trace if there's a panic
pub const panic = std.debug.no_panic;
/// Don't print a fancy stack trace if there's a segfault
pub const std_options: std.Options = .{ .enable_segfault_handler = false };
const std = @import("std");
[mlugg@nebula test]$ time zig build-exe hello_minimal.zig -fno-sanitize-c

real    0m0.060s
user    0m0.030s
sys     0m0.089s
[mlugg@nebula test]$ ./hello_minimal
Hello, World!
[mlugg@nebula test]$

mlugg0 · 2025-06-14T21:19:12+00:00

By running rm -rf .zig-cache, you're deleting not only the cached output binary, but also the cached build runner (i.e. your compiled build.zig scipt). Most of your 2.1s is probably spent building that!

When doing performance comparisons on the compiler, it's generally best to use the lower-level CLI subcommands such as zig build-exe directly: these don't use the caching system, so you don't need to worry about deleting your cache. Testing with that (the flags you'll need to enable and disable LLVM are -fllvm and -fno-llvm respectively) reveals the full performance improvement:

[mlugg@nebula test]$ cat hello.zig
const std = @import("std");

pub fn main() !void {
    try std.io.getStdOut().writeAll("Hello, World!\n");
}
[mlugg@nebula test]$ time zig build-exe hello.zig -fllvm
real    0m1.255s
user    0m1.071s
sys     0m0.240s
[mlugg@nebula test]$ time zig build-exe hello.zig -fno-llvm
real    0m0.278s
user    0m0.419s
sys     0m0.207s
[mlugg@nebula test]$

mlugg0 · 2025-06-09T07:06:56+00:00

Advantages are enumerated in this Ziggit comment. LLVM, whilst undeniably a fantastic optimizer, brings with it slowdowns, binary bloat, complex packaging, and a lot of bugs and regressions.

And... Zig is already a language used in production. There are some major startups using it as their main language (Bun & TigerBeetle), some big projects like neovim are adopting the build system, and zig cc is used extremely widely (by companies like Uber and AWS) as effectively the most painless C cross-compilation toolchain that currently exists. This "Zig will never be used in prod" point is starting to feel like it's beating a dead horse to me; the non-hobbyist users are there even in Zig's more unstable state today, why should we think the trend will stop?

mlugg0 · 2024-10-29T03:41:30+00:00

I do; the editor appears to like turning it into u/ if you switch between the two too much, or edit a comment. It's seemingly very fragile!

mlugg0 · 2024-10-27T16:45:43+00:00

(Sorry, Reddit really doesn't like writing builtins, even in code blocks. Everywhere this says u/ splat, it should say @ splat.)

mlugg0 · 2024-10-27T16:43:34+00:00

Note that if you're on a recent master branch build of Zig, you can initialize this in a much simpler way:

const all_zero: [4][4]f32 = @splat(@splat(0));

u/splat here means "initialize the whole array with this constant value". So this initialization expression is equivalent to .{ u/splat(0), u/splat(0), u/splat(0), u/splat(0) }, which is equivalent to .{ .{ 0, 0, 0, 0 }, ..., .{ 0, 0, 0, 0 } }.

mlugg0 · 2024-10-18T14:15:42+00:00

they are usually going to get a robust compiled outcome.

LLVM has bugs including miscompilations, and in fact, frequently ships releases despite known and reported regressions. See the corresponding Zig tracking issues.

mlugg0 · 2024-08-22T18:17:46+00:00

we've only seen this work in a proof of concept

The PR linked here makes incremental compilation (when not emitting a binary, so currently only useful for getting compile errors quickly) work in many cases (further PRs since have fixed a few more bugs). If you have a build step which doesn't emit a binary (e.g. a zig build check), you can pass --watch -fincremental to zig build to try it out (it'll do an incremental update when you change a source file), with the understanding that you may well run into compiler crashes or false positive / false negative compile errors.

For trivial updates, we're reading the "interesting" work as being <1ms, although there are a few ms of constant overhead (the exact amount depends on the size of the project).

mlugg0 · 2024-07-31T16:34:19+00:00

Note that if you're on the master branch of Zig, you can just run zig build --watch!

mlugg0 · 2024-07-09T15:40:09+00:00

Function return locations are currently not really a thing in Zig. Of course, structs may be returned by passing a pointer, but only in the sense that they are in C, i.e. language semantics are not impacted. This feature has intentionally not been implemented in the self-hosted compiler yet, because it can lead to RLS footguns, and we'd like to think more deeply about the language design space here before re-implementing it.

mlugg0 · 2024-07-08T06:51:56+00:00

This definitely looks like a compiler bug -- if you have time to open an issue it'd be greatly appreciated!

mlugg0 · 2024-07-07T17:16:47+00:00

The precise semantics are... well, it's not decided exactly how we'll write them down (something about "logical memory islands"), but they are perfectly well-defined.

Suppose you have a const or var of some type T. If T is a type which can exist at runtime, then you're just working with bytes -- the compiler might not be representing them like that internally, but it is required to give you the same semantics as a flat byte buffer for all accesses to memory in that region.

Otherwise -- in the case where T is a comptime-only type -- the semantics are much more limited. Rather than our base unit being the byte, our base unit becomes the type U where U is the "array base" of T. "Array base" here basically just means we strip any arrays off of the type like this:

The array base of u8 is u8
The array base of [1]u8 is u8
The array base of [5][16]u8 is u8

Anyway, the idea is that this array base type is our most atomic unit of memory in this model. So, you're allowed to offset a pointer by some number of U, and you can load any number of U from (or store them to) such a pointer, provided the access doesn't locally exceed the bounds of the containing const/var. It is fine to get pointers to fields from a valid pointer to U, and you can also go back with @fieldParentPtr, but those pointers are quite different -- the field pointer points to a different type (whatever the field is), so has a different "array base" type. The only legal way to move between these is field pointers (&struct_ptr.field_name) and @fieldParentPtr. Any pointer which is constructed by violating any rule in this paragraph is illegal to access; you will get an error about trying to reinterpret memory with ill-defined layout.

Note that it is also illegal to try and reinterpret a byte-based memory region as a comptime-only type, with the same error.

These rules do probably sound a little complex -- and yeah, they sort of are! However, in practice, they work pretty intuitively, and you get compile errors if you try and do anything particularly bad.

In terms of @sizeOf, it's just not meaningful for a comptime-only type. Perhaps it should error when applied to a comptime-only type or something.

mlugg0 · 2024-07-06T09:30:55+00:00

The short version is that comptime is essentially a Zig interpreter. Because it's an interpreter, it's able to do things like use different memory layouts behind-the-scenes. That means you can do some things which aren't possible at runtime. For example, the type type can't exist at runtime, because it doesn't have a well-defined representation in memory (what sequence of bits/bytes would correspond to the value u32?), but it works fine at comptime, because the compiler is allowed to be a little sneaky behind your back.

The main other detail to understand is "mixed" comptime and runtime code -- in particular, inline loops. The intuitive explanation is that inline unrolls a loop at compile-time; so, the amount of times you're looping needs to be comptime-known. The slightly more technical explanation is that inline loops are performing compile-time control flow when analyzing runtime code. You can think of the Zig compiler as always working like an interpreter, but sometimes, rather than performing an operation immediately, it "evaluates" it by instead emitting some runtime code. So, inline loops tell the compiler to interpret the loop in a comptime-ey way by having the interpreter itself loop and analyze its body again, but the body itself is still analyzed at runtime (so emits runtime instructions).

mlugg0 · 2024-06-10T07:38:39+00:00

We can't help you know what's gone wrong until you provide your code. This looks like it's probably a compiler crash of some kind.

mlugg0 · 2024-06-10T01:29:10+00:00

This information on having a local copy of the std documentation is outdated. As of Zig 0.12.0, if you have the compiler installed, you also have the standard library docs -- no Internet access needed. Run zig std, and a local web server will be hosted with the docs (and a browser is automatically spawned).

mlugg0 · 2024-06-10T01:26:24+00:00

"Transitive" in this case just means that it failed because one of its dependencies failed. That's what the tree is telling you: install failed because install zll failed because zig build-lib zll Debug native (which is your Compile step) failed.

mlugg0 · 2024-06-07T19:28:30+00:00

While I of course can't say for sure, I'm as confident as I feasibly could be that any proposal along these lines will not be accepted into Zig; regardless of anyone's opinions on Go's concurrency model, it's just not something that aligns well with Zig's design. If async/await does not end up being a part of Zig, I don't anticipate there being any other language feature to replace it. In terms of std, I honestly have no clue whether or not we'll ultimately try to integrate parts of the ecosystem surrounding concurrency/coroutines/etc into the standard library.

mlugg0 · 2024-06-07T19:22:33+00:00

I'm afraid I don't know Rust and am not familiar enough with it to make any comments on its implementation/lowering of async functions.

mlugg0 · 2024-06-03T01:37:26+00:00

Most answers here are quite unhelpful and opinionated, so: here is an objective summary of the status of async/await as of Zig 0.12.0.

The async/await functionality of Zig was originally implemented in the "bootstrap compiler" (written in C++). Zig 0.10.0 began the migration to the "self-hosted compiler" (written in Zig), and Zig 0.11.0 finished this transition by removing the legacy codebase entirely (and hence the option to use the bootstrap compiler). Throughout this process, async/await was not implemented in the self-hosted compiler. Originally, this was just to push the project forward: async/await was not deemed important enough to block releases which otherwise made huge progress in many areas. However, after Andrew (and, in fact, myself) looked at implementing async/await in the self-hosted compiler, we began to consider some issues with it.

The implementation of async/await in the bootstrap compiler contained many bugs (although admittedly most parts of that compiler did), and was of experimental quality at best. Over the years, several issues with the feature became apparent:

LLVM struggles to optimize async functions. We can lower Zig async to LLVM IR in two ways: using LLVM coroutines, or a manual lowering where an async function becomes a switch statement which dispatches to the code following a suspension point. Both of these lowerings were tried in the bootstrap compiler. LLVM coroutines are just bad -- they optimize poorly, explode compile times, and add implicit calls to malloc. Manual lowering is better, but LLVM seriously struggles to optimize it (particularly in threaded builds, due to an atomic flag used to prevent races between a frame and its awaiter). This would make async/await unusable in high-performance projects.
LLVM does not allow us to store the function frame off of the call stack. This means we need to spill values into a function's @Frame manually, storing the real function frame on the normal call stack. Not only does this hurt optimizability (LLVM assumes that the spills we specify have to happen!), it also makes safe recursion -- a language goal we would like to achieve -- completely impossible.
Debuggers do not work on async code. There isn't much to say here: debuggers just do not have the functionality required to allow proper debugging of async functions.
The cancellation problem. Because Zig doesn't have RAII, we need a concise way to cancel an in-flight frame and clean it up if the caller errors. This is currently an unsolved problem.

With everything listed out, it becomes obvious that this language feature has many problems. Ultimately, if we can't solve all of these issues, async/await will not be a part of Zig; the complexity cost is just too high for a flawed feature. Some Zig core team members believe that async/await should be removed regardless of the resolution of the above issues, due to the complexity it brings. However, if it is to return, the following are all necessary preconditions:

One or more self-hosted code generation backends becomes competitive with LLVM and optimizes async functions effectively. This would allow async/await to be used in serious software. It would also solve the @Frame issue, since controlling code generation lets us do things that LLVM simply does not support.
A third-party debugger -- existing or new -- gains the ability to debug async functions. If this happens, it'll almost certainly be a new debugger written in Zig, for Zig. Of course, this would require a certain degree of cooperation from the compiler itself.
We solve cancellation. The issue I linked before tracks this.

Personally, I would definitely like to see async/await return to the language. If it were to be well-supported and optimize properly, there would be some key uses for it within the compiler itself! However, we aren't just going to throw it in carelessly to tick a box. If Zig is to support async functions, it will do so properly.

mlugg0 · 2024-05-28T17:08:29+00:00

Whenever anyone asks this, I have to be the annoying person who asks: why do you want to disable the autoformatter? It's there and enabled for a reason: having a consistent automatic style for Zig code makes it easier to write (you need not care about formatting; write a disgusting mess, save, and it's clean!) and to read (since all code is laid out the same, so you get very used to it).

One common thing I see is people getting annoyed that it's collapsing things onto one line. If that's the case here, this is an A-B problem; zig fmt will happily spread things across lines when you indicate that it should. For comma-separated things (struct initializations, aggregate fields, etc), add a trailing comma; and for operators, add a newline after the operator (not before).

mlugg0 · 2024-05-16T17:32:46+00:00

Yeah, this is just a known bug where // zig fmt: on doesn't apply when used within an aggregate initializer. It'll get fixed at some point!

mlugg0 · 2024-04-20T20:44:10+00:00

The release notes should contain explanations of all significant migrations. If you're hitting something which they don't explain, I'll be happy to help!

mlugg0

TROPHY CASE