How many threads are actually getting utilized in those kernel builds? I don't work on the kernel enough to have intuition in mind but people make wildly optimistic assumptions about how compilation stresses processors.

Also 1st gen threadrippers are getting on a bit now, surely. It's a ~6 year old microarchitecture.

Kernel has thousands of compilation units. Each of them is compiled by a separate compiler process. Only the linking at the end doesn't parallelise, however it should take a much smaller part of the time. The proportions change of course, if you develop kernel and do incremental builds lots of times. Then the linking stage might become a bottleneck.

The above statement should also relate to most other C/C++ projects.

Kernel is C code though, which doesn’t require as much cpu to compile as say c++. It could be more IO bound. There should be a lot of more legit data available on this than my armchair speculations.

C++ adds a few time-consuming stuff, like templates, however my belief was that what uses the most time is optimization passes, which won't be much faster for C. The actual benchmarks should be done however.

Yes, it'd be interesting to see this comparison made with current AMD CPUs and a full build that has approximately the same price.

I am curious whether there is a real performance difference?

I do lots of computing on high-end workstations. Intel builds used to be extremely expensive if you required ECC. They used that to discriminate prices. Recent AMD offerings helped enormously. I wonder whether these M1 offerings are a significant improvement in terms of performance, making it worthwhile to cope with the hassle of switching architectures?

but do the m1s have ecc?

All of them. The CPU graph is pegged for most of the compilation.

Kernel compilation can be heavily parallelized.

I wouldn’t automatically expect a linear decrease in compile time with growing core count. That would have to be tried.