6 ms·

Zig Profiling on Apple Silicon

119 points by signa11 1y ago

turnsout 1y ago
This is cool! I'm anxious to dig into Zig on an M1, and this helps. Side note, the CSS is broken for me in Safari—I get this error: Cannot load stylesheet https://blog.bugsiki.dev/assets/css/stylesheet.b609c58d5c11bb90b1a54e04005d74ad1ddf22165eb79f5533967e57df9c3b50.css. Failed integrity metadata check. Content length: 4943, Expected content length: -1, Expected metadata: sha256-tgnFjVwRu5CxpU4EAF10rR3fIhZet59VM5Z+V9+cO1A=
christophilus 1y ago
Mostly unrelated, but I recently built a small utility in Zig, Hare, Go, Odin, and V. I never completed the Odin / V implementations since their standard libraries didn't have argon2 (a requirement for me). Of the group, I liked Odin's syntax and feel best. Hare was also very nice. But Zig's optimized binary sizes were unbeatable. 96KB vs 500KB for Hare and 2.5MB for Go. Zig's standard library and tooling are impressive. Personally, I wish more projects were written in Zig instead of Rust since Zig doesn't seem to have the package explosion problem that Rust has.
- Arnavion 1y ago
  There isn't anything fundamental about Zig that makes it immune from package explosion. It simply isn't popular and stable enough for that to have happened yet.
  - conradev 1y ago
    Zig's standard library is structured so that you only compile what you need, so Zig has no problems adding richer functionality to its standard library. This is influenced by Zig's decision to only have a single compilation unit per compile. HTTP, for example, can go into Zig's standard library, whereas C or Rust cannot do that. This helps control package explosion.
    - sionisrecur 1y ago
      As far as I know rust has dead code elimination. Is the problem that compilation takes longer?
    - Arnavion 1y ago
      The reason Rust doesn't have those things in libstd is because it doesn't want to commit to backward compatibility for them. Note that Rust is 1.0 and has no plans to switch to 2.0. Zig will presumably have the same care about backward compatibility once it becomes stable.
    - SkiFire13 1y ago
      On this topic, Rust just added an (unstable for now) option to delay codegen until needed https://blog.rust-lang.org/inside-rust/2025/07/15/call-for-testing-hint-mostly-unused/ https://blog.rust-lang.org/inside-rust/2025/07/15/call-for-t... 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.
      - BrouteMinou 1y ago
        And potentially, 4 times the number of different authors, and 4 times the supply chain attack potential. It's not just about the number of bytes.
        1y ago
- CJefferson 1y ago
  Why do you think Zig won't have the same issue? In my experience lack of packages seem to come from no standard place to put them (C++, then you end up with effective package stores like Boost), or just not popular enough. Most languages I work on (Rust, Python, JavaScript, Haskell), have a huge number of packages.
  - treyd 1y ago
    I think that the "package explosion problem" actually does exist in C/C++ and Go but it's just hidden. Very often a project takes the form of various components, and you only depend on a subset of them. In these older-style languages these are all shipped as a single unit, but in newer languages these are shipped more explicitly so you can see what the shape of your dependency tree really looks like. Boost is a great example of this, since it does a ton of different things, but the boundaries between components are not quite as obvious as having a "dependencies.lock" to look at. Tokio has a ton of different packages but often you only need a few of them.
    - SkiFire13 1y ago
      Also often dependencies can be hidden by depending on a single system library, but that then internally contains a ton of stuff. Let's be real about dependencies: https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies
      - kbolino 1y ago
        The other thing, which is also a double-edged sword, is that "system dependencies" on Linux (generally) have only one version installed at a time and that version is expected to be suitable for all dependents. Distro managers/packagers often put in nontrivial work to make this happen. So you often install something new with few apparent dependencies because the rest are already installed. With dependency locking in Rust etc., you'll often "re-"install the same package many times because the version is slightly different than what you already had.
- dragonelite 1y ago
  Its was so nice to just quickly write up a static file server. Just to play with wasm without needing to use the usual python http server thingy. I was told the std.http.* isn't meant to be used for production servers but its nice that i now have a drop in zig file that contains a very very... bare bones static file server i can add to zig projects that might need it.
saagarjha 1y ago
Just use Instruments. Yes, I know it’s slow, but it’s miles ahead of anything on Linux. If you’re looking for an identical profiling experience on macOS as you get on Linux you’re greatly missing out.
- ForLoveOfCats 1y ago
  XCode is painful but I always miss Instruments whenever I'm profiling something on my Linux systems
  - Cloudef 1y ago
    perf top
    - saagarjha 1y ago
      perf top is Instrument's "top functions" sampler. It doesn't get used all that often because there are much better ways to process this information.
- verte_zerg 1y ago
  What kind of extra functionality are you getting from Instruments that isn't covered by other tools?
  - dagmx 1y ago
    Other than just the niceness of the interface, a key one is that the M4 generation added profiling of CPU branching and afaik instruments is the only thing that supports it right now
    - verte_zerg 1y ago
      In the M4, Apple mostly added counters only for the SME engine. The full list of supported counters can be found in the official guide: https://developer.apple.com/documentation/apple-silicon/cpu-optimization-guide https://developer.apple.com/documentation/apple-silicon/cpu-... 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.
ethan_smith 1y ago
For low-overhead Zig profiling on Apple Silicon, you can also use DTrace with the pid provider to sample stacks without modifying your code or relying on Instruments' UI.

119 points by signa11 1y ago

This is cool! I'm anxious to dig into Zig on an M1, and this helps. Side note, the CSS is broken for me in Safari—I get this error: Cannot load stylesheet https://blog.bugsiki.dev/assets/css/stylesheet.b609c58d5c11bb90b1a54e04005d74ad1ddf22165eb79f5533967e57df9c3b50.css. Failed integrity metadata check. Content length: 4943, Expected content length: -1, Expected metadata: sha256-tgnFjVwRu5CxpU4EAF10rR3fIhZet59VM5Z+V9+cO1A=

christophilus 1y ago

Mostly unrelated, but I recently built a small utility in Zig, Hare, Go, Odin, and V. I never completed the Odin / V implementations since their standard libraries didn't have argon2 (a requirement for me). Of the group, I liked Odin's syntax and feel best. Hare was also very nice. But Zig's optimized binary sizes were unbeatable. 96KB vs 500KB for Hare and 2.5MB for Go. Zig's standard library and tooling are impressive. Personally, I wish more projects were written in Zig instead of Rust since Zig doesn't seem to have the package explosion problem that Rust has.

Arnavion 1y ago
There isn't anything fundamental about Zig that makes it immune from package explosion. It simply isn't popular and stable enough for that to have happened yet.
- conradev 1y ago
  Zig's standard library is structured so that you only compile what you need, so Zig has no problems adding richer functionality to its standard library. This is influenced by Zig's decision to only have a single compilation unit per compile. HTTP, for example, can go into Zig's standard library, whereas C or Rust cannot do that. This helps control package explosion.
  - sionisrecur 1y ago
    As far as I know rust has dead code elimination. Is the problem that compilation takes longer?
  - Arnavion 1y ago
    The reason Rust doesn't have those things in libstd is because it doesn't want to commit to backward compatibility for them. Note that Rust is 1.0 and has no plans to switch to 2.0. Zig will presumably have the same care about backward compatibility once it becomes stable.
  - SkiFire13 1y ago
    On this topic, Rust just added an (unstable for now) option to delay codegen until needed https://blog.rust-lang.org/inside-rust/2025/07/15/call-for-testing-hint-mostly-unused/ https://blog.rust-lang.org/inside-rust/2025/07/15/call-for-t... 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.
    - BrouteMinou 1y ago
      And potentially, 4 times the number of different authors, and 4 times the supply chain attack potential. It's not just about the number of bytes.
      - 1y ago
CJefferson 1y ago
Why do you think Zig won't have the same issue? In my experience lack of packages seem to come from no standard place to put them (C++, then you end up with effective package stores like Boost), or just not popular enough. Most languages I work on (Rust, Python, JavaScript, Haskell), have a huge number of packages.
- treyd 1y ago
  I think that the "package explosion problem" actually does exist in C/C++ and Go but it's just hidden. Very often a project takes the form of various components, and you only depend on a subset of them. In these older-style languages these are all shipped as a single unit, but in newer languages these are shipped more explicitly so you can see what the shape of your dependency tree really looks like. Boost is a great example of this, since it does a ton of different things, but the boundaries between components are not quite as obvious as having a "dependencies.lock" to look at. Tokio has a ton of different packages but often you only need a few of them.
  - SkiFire13 1y ago
    Also often dependencies can be hidden by depending on a single system library, but that then internally contains a ton of stuff. Let's be real about dependencies: https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies
    - kbolino 1y ago
      The other thing, which is also a double-edged sword, is that "system dependencies" on Linux (generally) have only one version installed at a time and that version is expected to be suitable for all dependents. Distro managers/packagers often put in nontrivial work to make this happen. So you often install something new with few apparent dependencies because the rest are already installed. With dependency locking in Rust etc., you'll often "re-"install the same package many times because the version is slightly different than what you already had.
dragonelite 1y ago
Its was so nice to just quickly write up a static file server. Just to play with wasm without needing to use the usual python http server thingy. I was told the std.http.* isn't meant to be used for production servers but its nice that i now have a drop in zig file that contains a very very... bare bones static file server i can add to zig projects that might need it.

saagarjha 1y ago

Just use Instruments. Yes, I know it’s slow, but it’s miles ahead of anything on Linux. If you’re looking for an identical profiling experience on macOS as you get on Linux you’re greatly missing out.

ForLoveOfCats 1y ago
XCode is painful but I always miss Instruments whenever I'm profiling something on my Linux systems
- Cloudef 1y ago
  perf top
  - saagarjha 1y ago
    perf top is Instrument's "top functions" sampler. It doesn't get used all that often because there are much better ways to process this information.
verte_zerg 1y ago
What kind of extra functionality are you getting from Instruments that isn't covered by other tools?
- dagmx 1y ago
  Other than just the niceness of the interface, a key one is that the M4 generation added profiling of CPU branching and afaik instruments is the only thing that supports it right now
  - verte_zerg 1y ago
    In the M4, Apple mostly added counters only for the SME engine. The full list of supported counters can be found in the official guide: https://developer.apple.com/documentation/apple-silicon/cpu-optimization-guide https://developer.apple.com/documentation/apple-silicon/cpu-... 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.

ethan_smith 1y ago

For low-overhead Zig profiling on Apple Silicon, you can also use DTrace with the pid provider to sample stacks without modifying your code or relying on Instruments' UI.