Zig Profiling on Apple Silicon

Just like Zig's decision it is a double edged sword: on one side you can avoid compiling code that will not be needed. However on the other side you make incremental compilation worse, since you will have to recompile it more often.

> HTTP, for example, can go into Zig's standard library, whereas C or Rust cannot do that.

Rust _could_ put HTTP in the standard library, the dead code would simply be removed when linking. The reason it's not in the stdlib has more to do with the fact that:

- it would need to be supported by a team that's already overworked - it would need to be supported indefinitely, so it would have to be the right interface on the first try.

This effectively prevents any big and complex feature from making to the Rust stdlib.

> This helps control package explosion.

Arguably it helps controlling the number of "packages", but not the amount of code in those packages. If I split a "package" in 4 crates in Rust to get better compile times it's still mostly the same code, but you now see a number 4 times bigger.

Zig will presumably have the same care about backward compatibility once it becomes stable.

Yes they can? If you look at old-timey C libraries, for example (standard or otherwise), you’ll see that they have the relatively awkward structure of one public function per file. That’s an adaptation for static linking, which only pulls in the object files that contain symbols required by the program, thus it’s beneficial to make the object (and therefore source) files as small as possible. Yes, the compiler still needs to produce of these object files, but unlike with Zig it only needs to do so once per (separately compiled) library.

An inferior emulation of the same trick, popular in the embedded community, is passing --gc-sections to ld, but unless you’re very careful something will fall off that you weren’t planning on. (Of course C++ makes things more complicated, as always, so you may be forced to use this option.)

Glibc’s (and specifically Drepper’s) aversion to static linking did us all a disservice by making static libraries less popular.

This does not mean that there isn’t some benefit to whole-program compilation. E.g. GCC can derive assumptions about a non-exported function’s arguments and propagate them into the function’s body even if it does not decide to inline it (look for “constprop” symbols in objdump). So that’s also a thing that people do, in particular in gamedev where the somewhat stylized source code structure it requires is less of a problem. (Game developers confusingly call this a “unity” build—personally I prefer the term “amalgamation” used by Lua and SQLite.)

> so Zig has no problems adding richer functionality to its standard library.

That’s orthogonal to both

- whether to compile from source in every compilation unit or to compile once, and use (shared) libraries,

and to

- whether to provide the standard library as a single unit, as is typically done in C, where it is a (shared) library, or as multiple interdependent smaller units as in Zig, where the standard library contains multiple source files.

> HTTP, for example, can go into Zig's standard library,

The claim “you only compile what you need” also is incorrect. Zig’s source files (luckily) aren’t fine-grained enough to support that.

For example, https://github.com/ziglang/zig/blob/master/lib/std/http/Clie... contains stuff that not every user of that module will need, for example connection pools and a function to flush a buffer.

The compiler may not generate code for such unused definitions, but it has to parse them, if only to figure out where the next definition starts.

Regarding branch profiling, all arm64 (M1+) cpus support these counters: - BRANCH_CALL_INDIR_MISPRED_NONSPEC - BRANCH_COND_MISPRED_NONSPEC - BRANCH_INDIR_MISPRED_NONSPEC - BRANCH_MISPRED_NONSPEC - BRANCH_RET_INDIR_MISPRED_NONSPEC - INST_BRANCH - INST_BRANCH_CALL - INST_BRANCH_COND - INST_BRANCH_INDIR - INST_BRANCH_RET - INST_BRANCH_TAKEN

afaik there is no limitation to implementing the fetching of all these counters based on ibireme’s research on kperf. btw, forked "poop" already can fetch BRANCH_MISPRED_NONSPEC.