Ask HN: Is an AMD Threadripper a good idea to speed up code compilation?

2 points by valty ↗ HN
I want to build big projects like Chromium, WebKit and LLVM as fast as possible.

I think it would be nice to have a rig to just be building code and running tests all the time.

Thoughts?

11 comments

[ 3.6 ms ] story [ 32.6 ms ] thread
I loved my Threadripper 1950x. But processors inevitably age out. Mine's sitting in a cupboard unused.

I upgraded to an i5-1360K. A friggin' i5!

Check it out: https://cpu.userbenchmark.com/Compare/Intel-Core-i5-13600K-v...

I really wish there were more crazy-core-count CPUs out there, but the Threadripper prices are pretty nuts, especially if they're superseded by i5s and i7s in a few years.

Do not use userbenchmark for speed comparison. Ever. They are not user based. They are essentially a marketing scheme by Intel to make AMD look bad. Just search userbenchmark on YouTube and the first suggestion will be `userbenchmark bias`. See 2kliksphilip video about them https://www.youtube.com/watch?v=RQSBj2LKkWg
I'd say this usage is very specific - that the best way to move forward would be to run the workload on real hardware. You might get a huge benefit from a high-core count in certain projects while other codebases will build faster on fewer cores with higher single-thread performance.
> the best way to move forward would be to run the workload on real hardware.

OP is asking whether the hardware will perform so he know whether to buy it. Is the "best way to move forward" really to buy the hardware and find out?

If you can return it if it doesn't fit the need, then yes. You can also model approximations with cloud servers.
I would just love some trustworthy data rather than a youtuber conspiracy video. Show a benchmark!

Are their facts wrong? Number of cores? Clock speed? TDP?

Or maybe its the nature of their writing:

Intel: "Intel’s 13th gen. Raptor Lake CPUs offer around 10% faster gaming and 45% faster multi-core performance than their predecessors."

AMD: "AMD’s 16 core, 32 thread Ryzen Threadripper 1950X is finally here to seize the throne for high end desktop processors."

Feel that PRO-INTEL bias!

Are the users in on the scam too?: https://www.userbenchmark.com/Software

The real problem is the c++ of chromium, webkit and llvm, which is a nightmare to compile.

But actual chromium, webkit and llvm are already problems by themselves with their grotesque and absurd complexity and size.

Oh and rust is llvm in the backend, and its syntax is hardly less complex.

No salvation here, same same.

Hard to say without benchmarking. Unless the compilation process can be parallelised (as in "lots of files without interdependencies"), you'll find little use for extra cores beyond the average number of simultaneous possible compilations.

This is all very project-dependent - you might even optimise your build process by moving things around to reduce these dependencies (facilitating parallel compiles).

imho. (!)

idk. but you have to think about mainly one thing:

how well does the "overall" task you want to achieve scale with the core-count!?

test it with your existing hardware ... idk:

# run the compilation(s) with 1, 2, 4, 8, 16 cores

# look at the results ... how well does it scale with the core-count

think about your actual use-case:

# single build vs multiple ones on one system at a time

# how much of the build-performance comes from i/o ... ;)

what i discovered for certain project in the past:

sometimes test-runs are the most time-demanding part of a projects build and sometimes testing doesn't scale well with the cpu-core count... you need a compile/worker task per core to utilize your cpu ... so often really large core-numbers don't result in an additional speed-up (remember amdahls law ;)

on the other side: if you plan to run multiple such build-jobs in parallel, it might make sense to have a lot of cores ...

again: don't forget to measure the impact of i/o ... especially if you want to run multiple build-jobs in parallel.

and: while threadrippers are great cpus - i have to admit, that i'm a big amd fan ;))

... maybe the result is, that it won't scale well beyond lets say 8 cores for a single build-jobs or 16 / 32 cores for multiple jobs => stay with a good desktop-processor avoiding the ones with "energy-efficient" cores like the plague...

ps. personally i try to solve such problems with hardware with a good price/performance ratio ... don't "overspend", just because you think it makes sense. benchmark/measure!!

then go for a cheap box first, if it proofs your hypothesis and you do have a lot of tasks at your hand and time = money in your environment => just buy a second one etc.

if you have a lot of jobs: think about a job-scheduler ... etc.

just my 0.02€