Hacker News Reader

Comment by celeritascelery | Hacker News Reader

For me the single biggest factor is still single threaded performance. There are still many apps that are not multithreaded so all those extra cores are useless. Single thread performance will benefit any application. Intel still holds the lead in this category.

View on HN

I don't like this argument for three reasons:

1. The single thread performance gap is very small (5-10% depending on application) or even non-existent in some cases.

2. Your computer runs more than one process at any given moment. The more cores, the more processes you can run without an impact on performance

3. That single core performance comes at the cost of efficiency and general power usage. Intel has had to clock their 14nm process very high to achieve that small lead in single thread performance.

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.

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.

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

> 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.

It also assumes that this important single threaded process's dev team isn't actively working on parallelizing it. And that the primary purpose of the computer will be running this process until its end of life. Both pretty bad assumptions given the minimal benefit and high cost.

Intel holds a minuscule lead here, not enough to be worth thinking about; especially against the Zen 2 architecture (Ryzen 3000 series chips).

Wanting an Intel over a Zen 1 for single threaded performance? Completely understandable.

IPC on Zen 2 is arguably slightly ahead of Intel, but they don't overclock or boost to 5Ghz.

Marginally, and not really when perf/$ is taken into account...

Multi core performance is still useful if you are running many single-threaded applications at once.

If you are running many single-threaded applications at once AND if you care about their performance. For example my Windows might run some background processes from time to time, but I don't care about their execution time, all I care is about my foreground application.

I initially felt similar regrets after purchasing my 2950X. Obviously, the advantage with this CPU is being able to go wide on all cores, not necessarily maxing out any particular one. And it does work in a lot of cases. I regularly see 100% CPU when running rebuilds of large .NET Core applications. But, I also recognize that on a single-thread basis, I don't really have any advantage over anyone else (potentially even a small deficit).

But, this is a narrow-minded perspective to have. The future cannot possibly be that we magically invent an x86 core that can clock to 8GHz w/ practical power & cooling. One has to push forward in some incremental way. The answer is adding more parallel execution units. Sure, lots of software and techniques used today are not feasible to directly port over, but that doesn't mean it has to stay that way.

As a software developer, I feel it is my duty to help push the state of the art forward wherever possible. I have already begun working on projects that are designed around the concept of extremely high core counts becoming the norm. Having 32 logical threads sitting in your local workstation makes it possible to practically experiment with the lower bounds of what would be required in a larger production deployment.

There are types of software that we can consider building today that would have sounded absolutely insane just a few years ago. Cloud gaming is now a thing falling within practical reach. How many more x86 cores per instance would we need before we could start thinking about rendering 100% of client views server-side (i.e. eliminate most HTML/CSS/JS) or deprecating the usefulness of discrete GPUs altogether? Pulling everything into a single memory domain could do wonders for breaking down the ages-old GPU/CPU functionality silos. One way to do it all with one instruction set and a single cache-coherent memory architecture...

Barely, if at all. Not all benchmarks have been done with all exploit mitigations we have today. Also AMD is cheaper per performance.

You could still say AMD has an advantage. Given the cost difference, and the fact that Intel usually changes socket types each release, you could purchase a new AMD SKU every year and always have the latest. For the same price you'd probably have to be working with three or four year old Intel technology at some point. By that time the newer AMD SKU would be putting the old Intel processor to shame.

Of course if price is no object then the above doesn't apply.

> There are still many apps that are not multithreaded

Can you give some examples of CPU intensive apps that are not multi threaded in 2020?

I’m a structural engineer, running nonlinear analyses of buildings. These take about 3-5 days to run on an i9-9900k. The program runs each earthquake simulation on a single core.

Man, this is just begging for parallelization.

I can make multiple instances to run multiple simulations in parallel, but matrix factorisation within the program itself is single-threaded. The stiffness matrix of these structures needs to be reformulated frequently (every time a structural element yields / gets damaged), so this is the largest time-sink, I think.

thats just a shitty program lol

I'm not disagreeing with you... Its horrible but that is the industry standard.

Honestly my biggest problem right now is that I don't even know if there's anything I can buy/upgrade to speed it up. I don't know how to determine what the bottleneck is, so to speak.

An audio processing chain is necessarily single-threaded. e.g. if you want to simulate a guitar rack you have to first simulate the distortion pedal before the amp, the amp before the cab, the cab before the delay / reverb / whatever 200 other effects you're chaining. And you have to do all that in tight deadlines, e.g. <= 2 milliseconds.

A single signal path on its own yes that’s true, but DAWs have been multithreaded for years now using threads for other signal paths. Some DAWS can even use threads for FX chains now too.

you're preaching to the choir - my own DAW, https://ossia.io has no issue distributing tasks on their own cores. That does not help me at all when I just want to add that one more effect to a live guitar track.

Stop using Python for time critical applications ;-)

Docker is a thing now, though.

Reply on news.ycombinator.com