Hacker News Reader

Comment by kiratp | Hacker News Reader

My workstation has a 3990x.

Our "world" build is slightly faster on my M1 Max.

https://twitter.com/kiratpandya/status/1457438725680480257

The 3990x runs a bit faster on the initial compile stage but the linking is single threaded and the M1 Max catches up at that point. I expect the M1 Ultra to crush the 3990x on compile time.

View on HN

Are both cases compiling to the same target architecture? If not, you may well be comparing the relative performance of different compiler backends instead of comparing the performance of your CPUs.

(+ now I see it's rust: how parallel is your build, really?)

that the arm backend is faster to compile for is a legit advantage for the developer though, even if its distinct from cpu perf

> now I see it's rust: how parallel is your build, really?

Not the OP but I install a lot of Rust projects with Cargo and recently did some benchmarking on DigitalOcean's compute-optimized VMs. Going from 8 cores to 32 cores was a little disappointing:

Bat (~40 crates): 68s -> 61s

Nushell (486 crates): 157s -> 106s

Compilation starts out highly parallel and then quickly drops down to a small number of cores.

The target arch doesn’t matter for the change-build-test loop d vs do. All that matters is how fast can you compile your code to test it.

If the final x86 production build takes longer it doesn’t matter - that happens on the cloud anyway.

Edit: Rust builds are very parallel until linking. No different than any other LLVM build.

> The target arch doesn’t matter for the change-build-test loop d vs do.

It matters when comparing CPU performance, which is what this benchmark is being used for.

> The 3990x runs a bit faster on the initial compile stage but the linking is single threaded and the M1 Max catches up at that point.

Isn't linking IO-bound?

Exposing my limited understanding of that level of the computing stack - it is but Apple seems to have very very good caching strategies - filesystem and L1/2/3.

https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf

There is a breakdown in those slides discussing what parts of lld are single threaded and hard to parallelize so I suspect single thread performance plays a big role too. I generally observe one core pegged during linking.

> Exposing my limited understanding of that level of the computing stack - it is but Apple seems to have very very good caching strategies - filesystem and L1/2/3.

That would mean that these comparisons between Threadripper and the M1 Ultra do not reflect CPU performance but instead showcase whatever choice of SSD they've been using.

L1/2/3 are CPU caches, not SSD. Though there is a good chance these are mostly firmware optimizations, not hardware. So still not an apples-to-apples comparison of cpu design.

By firmware you mean microcode, but I don't think either of those actually use microcode to control this.

> L1/2/3 are CPU caches, not SSD.

Why did you omit the reference to "file system"?

Are we supposed to ignore the fact that a linker's main job is reading object files and write the output to a file?

I find this sort of argument particularly comical given a very old school technique to speed up compilation is to use a RAM drive to store the build's output.

https://github.com/rui314/mold would suggest otherwise. Massive speedups by multithreading the linker. I think traditional linkers just aren't highly optimised.

> https://github.com/rui314/mold would suggest otherwise.

Does it, though?

I mean, if you read that link you'll notice it boasts the linker's performance by comparing it with cp and how it's "so fast that it is only 2x slower than cp on the same machine."

Is cp supposed to be CPU-bound?

The data the linker is running on will generally largely be in memory (in their posted example, which is a warm compile, completely in memory).

Yes, but that's for mold, which is multithreaded. The original context of this thread being the question of whether a linker would see speedups from multithreading. Most people are using traditional single-threaded linkers which are an order of magnitude slower than mold. The fact that mold is so much faster suggests that a linker does indeed see big speedups from multithreading.

For a clean build and a reasonably specced machine, all the intermediate artifacts will still be in the cache during linking.

Do you have any benchmarks of the two to share against a mean to ensure its built optimally? Maybe something like https://opendata.blender.org ? It's painful hearing random anecdotes only to learn the person didn't apply thermal paste to their cpu.

From the tweet reply you used sccache with hot cache, which would probably be mostly single-threaded since it's just fetching and copying things from cache.

I’m not trying to compare the details of SOC performance.

Just that with the same hot caches, the average change-build-test loop that developers do 100+ times a day is just faster on the M1 Max.

Try mold.

We plan to move to it once MacOS support lands (for the laptops).

>Try mold

Curiosity got the better of me:

https://github.com/rui314/mold

Intel was the single-threaded king until Zen3, so that's no real surprise.

Try the same thing with mold.

Reply on news.ycombinator.com