9 ms·

My workstation has a 3990x. Our "world" build is slightly faster on my M1 Max. https://twitter.com/kiratpandya/status/1457438725680480257 https://twitter.com/

• howinteresting 5y ago
  Try mold.
  • kiratp 5y ago
    We plan to move to it once MacOS support lands (for the laptops).
  • petecooper 5y ago
    >Try mold Curiosity got the better of me: https://github.com/rui314/mold https://github.com/rui314/mold
• fivea 5y ago
  > 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?
  • kiratp 5y ago
    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 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.
    • fivea 5y ago
      > 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.
      • LordDragonfang 5y ago
        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.
        • astrange 5y ago
          By firmware you mean microcode, but I don't think either of those actually use microcode to control this.
        • fivea 5y ago
          > 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.
  • nicoburns 5y ago
    https://github.com/rui314/mold https://github.com/rui314/mold would suggest otherwise. Massive speedups by multithreading the linker. I think traditional linkers just aren't highly optimised.
    • fivea 5y ago
      > https://github.com/rui314/mold 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?
      • rsynnott 5y ago
        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).
      • nicoburns 5y ago
        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.
  • codeflo 5y ago
    For a clean build and a reasonably specced machine, all the intermediate artifacts will still be in the cache during linking.
• zerd 5y ago
  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.
  • kiratp 5y ago
    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.
• atq2119 5y ago
  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?)
  • gameswithgo 5y ago
    that the arm backend is faster to compile for is a legit advantage for the developer though, even if its distinct from cpu perf
  • ripley12 5y ago
    > 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.
  • kiratp 5y ago
    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.
    • runeks 5y ago
      > 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.
• daniel-grigg 5y ago
  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 https://opendata.blender.org ? It's painful hearing random anecdotes only to learn the person didn't apply thermal paste to their cpu.
• zamalek 5y ago
  Intel was the single-threaded king until Zen3, so that's no real surprise. Try the same thing with mold.