RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
82% Positive
Analyzed from 1035 words in the discussion.
Trending Topics
#zig#build#bun#more#https#rust#compilation#com#something#compile
Discussion (30 Comments)Read Original on HackerNews
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!
A) Is there any performance penalty on the compiled result due to being optimized in separate pieces
B) If not, why isn't the optimizer smart enough to split them up internally and optimize in parallel?
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 believe there is a fork of bun from 1.3 that a different community is maintaining. I wonder if they’ve been able to get the compile times down by modularizing the build?
There is Buz effort to do this which might be worked at, behind the scenes: https://github.com/jazzzooo/buz
(I'm looking forward to looking into Zig)
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 bun team tried to parallelize Zig's semantic analysis a while back - and it DID compile about 4x as fast... YET the builds were no longer deterministic, which is a hard requirement for lots of things. More effort will need to be spent here than naively adding a thread pool. Hopefully Zig's Sema.zig gets faster, but Rust is also super slow at compiling and needs to improve. 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.
There's an enormous amount of analysis you can do with tools like this from estimating how much faster the build would be with more cores (i.e. is it worth adding more) to things like a diff of one build against another: why is one build bad and the other good - what tasks had different parameters or weren't in both builds?
It's quite odd how everything gets re-invented isn't it? N years ago I didn't think that javascript would ever have a "build time" problem but I've already been asked if I can write a "filesystem" for one well known web platform and I wondered if they wanted something like EFS. I obviously said no because I didn't feel like trying to pretend that I write filesystems three times a year.
What would the macOS equivalent be?
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
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.
“I did this cool useful thing”
“Great! Please describe how I can get a machine to replace you.”
You can also use --compiler-traces to understand the inside of the linking process as well; these annotations are provided by lld.