Joined 5 years ago
If you mean "how would I implement it without ptrace", there are a few options but likely the Endpoint Security API [1] would be the way to go. But it's not too great because it needs full disk access and root, neither of which I would be particularly happy accepting :(
[1] https://developer.apple.com/documentation/endpointsecurity
You can also use --compiler-traces to understand the inside of the linking process as well; these annotations are provided by lld.
AFAIK, the answer to this is no but only if LTO is doing a good job and actually optimizing well across object files.
> B) If not, why isn't the optimizer smart enough to split them up internally and optimize in parallel?
I think there was another comment by someone more knowledgable in Zig that this is something which is being discussed by the Zig compiler team.
I actually collected a build with multi-threading turned on [1]. It helped quite a bit, cutting the Zig object time from 7m49s to 4m05s. But because of the reason you mentioned (and the post was already so long!) I decided not to bring it up.
> Oh - one last thing to note, Zig has very fast debug compilation and incremental compilation, it's a real nice thing to work with that you simply can't approach in most other languages right now.
Yes, in fact I also tested just running bun run build / bun run build:release and captured traces for both! The clean release build took 3m36s for Zig versus 5m50s for Rust [2][3]. Clean debug was closer: 3m07s versus 3m27s [4][5].
I also tried incremental debug builds: adding a comment to output.zig / output.rs took 48.6s / 65.4s to rebuild. Ordinary developer builds certainly gave a different picture from CI.
[1] https://buildprof.lalitm.com/#!/?url=https%3A%2F%2Fblogexamp...
[2] https://buildprof.lalitm.com/#!/?url=https%3A%2F%2Fblogexamp...
[3] https://buildprof.lalitm.com/#!/?url=https%3A%2F%2Fblogexamp...
[4] https://buildprof.lalitm.com/#!/?url=https%3A%2F%2Fblogexamp...
[5] https://buildprof.lalitm.com/#!/?url=https%3A%2F%2Fblogexamp...
I added a Python script wrapping rustc which serializes all rustc invocations for bun_* crates; you can find the recoridng at [1]. Turns out it only increased the build by 1 minute! So clearly my intuitition that it was just crate parallelism was not correct.
One more confounding factor though is that rustc is parallelised while Zig's compiler is not (yet). So it's still possible that might be the reason.
[1] https://buildprof.lalitm.com/#!/?url=https%3A%2F%2Fblogexamp...
The fix seemed to be to split up Bun's Zig module into ~100 pieces just like they've done on Rust but how representative that would have been on anything Bun might of shipped is very much in question!
But I still think the visual view is invaluable for human understanding and for the "why is this even happening" problems which I think AI is still bad at seeing.
Provides great context on this accomplishment, what it means but also doesn't mean.
Thanks!
