Hacker News Reader

Comment by Theodores | Hacker News Reader

The key words in the parent post are 'for me'.

Imagine you have a single core compilation process that takes two minutes that you must run 50 times a day. This can happen. Ten percent brings 12 seconds per compile or ten minutes a day. This might not sound great but it means you can get an extra five compiles done. You can also get increased likelihood that you can remember what you were working on. Therefore the marginal gain in single thread performance is well worth having in this use case. The expense of genuine Intel becomes worth it even if you don't have so many cores.

View on HN

I have a dual core dev machine. Using -j 2 builds twice as fast (approx 35 mins -> 17 mins). Are current compiles really obligatory single thread? Because I sure would like to prop up intel with my wallet.

Anything JavaScript for example is single threaded for the most part. Also something like linking is typically in parallelized.

thats not the compilation process. that's just javascript.

the compilation definitely has parallelism.

You’d be surprised...

Most web development toolchains depend on Node.js, which compiles on a single core.

Sure, but you're also running a browser at the same time probably with a ton of tabs open as separate processes. Our computers do quite a lot these days, in parallel, and more cores help.

Both AMD and Intel are ridiculously fast! You can't really go wrong with either.

which then shard out to multi processes, still benefitting from more cores being available. I know of at least a few build processes that support that model for node.

Node takes advantage of multiple cores.

The code is all async by default and that is easy to load onto green threads.

This used to be implemented with callback hell, now it's Promises which is actually really cosy (and what Rust is adopting).

Random article I found on it: https://medium.com/better-programming/is-node-js-really-sing...

FreePascal is single threaded

But it is also like 10 times faster than other compilers.

> Imagine you have a single core compilation process

Who runs builds with a single core compilation process? Are we back in 1990?

You are hard-pressed to find a CPU with a single core nowadays, even in the cheapest of consumer segments. Why are you fabricating such an unrealistic case?

The linking phase for C and C++ software is basically linear. Nobody's figured out how to multi thread that since before 1990. It takes hours to build large software (Chrome/Firefox/Qt).

By the way, one of the biggest improvements in software performance in the past decade comes from link time optimisations during build (LTO), that's all done during linking and it takes FOREVER.

gold has had threading support since its release in 2008. Likewise for lld, which is an order of magnitude faster than gold.

From anecdotal experience of the code I am on right now, relinking a few hundred megabytes of .o's takes less than 2 seconds with lld on my 6900k.

> The linking phase for C and C++ software is basically linear.

Depends how many targets you're building. If you have enough memory, you can link several libraries in parallel.

> The linking phase for C and C++ software is basically linear.

Linking is also IO-bound, and already a solved problem in the sense that there are already plenty of solutions that render linking to be a non-issue. It's far from a decent CPU benchmark.

The key phrase was 'for me'. That 'me' could be working on an existing code base that does a bit more than show a web page and can't be written in flavour of the month toolkits.

Build processes that run on more than one job at a time is not a flavour of the month: it's the industry standard of the last 20 or 30 years.

fix your compilation process. there are few long running workloads that don't benefit from parallelism.

Reply on news.ycombinator.com