9 ms·

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

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.

djd20 6y ago
Marginally, and not really when perf/$ is taken into account...
hddherman 6y ago
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.
- Theodores 6y ago
  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.
  - throwaway_pdp09 6y ago
    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.
    - tbrock 6y ago
      Anything JavaScript for example is single threaded for the most part. Also something like linking is typically in parallelized.
      - jatone 6y ago
        thats not the compilation process. that's just javascript. the compilation definitely has parallelism.
        tbrock 6y ago
        You’d be surprised...
    - chitza 6y ago
      Most web development toolchains depend on Node.js, which compiles on a single core.
      - kohtatsu 6y ago
        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-single-threaded-7ea59bcc8d64 https://medium.com/better-programming/is-node-js-really-sing...
      - oppositelock 6y ago
        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.
      - jatone 6y ago
        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.
  - jatone 6y ago
    fix your compilation process. there are few long running workloads that don't benefit from parallelism.
  - rumanator 6y ago
    > 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?
    - user5994461 6y ago
      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.
      - jcelerier 6y ago
        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.
      - TazeTSchnitzel 6y ago
        > 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.
      - rumanator 6y ago
        > 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.
    - Theodores 6y ago
      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.
- daxfohl 6y ago
  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.
GhostVII 6y ago
Multi core performance is still useful if you are running many single-threaded applications at once.
- vbezhenar 6y ago
  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.
s9w 6y ago
Barely, if at all. Not all benchmarks have been done with all exploit mitigations we have today. Also AMD is cheaper per performance.
dannyw 6y ago
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.
- philjohn 6y ago
  IPC on Zen 2 is arguably slightly ahead of Intel, but they don't overclock or boost to 5Ghz.
grecy 6y ago
> 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?
- ggcdn 6y ago
  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.
  - dvfjsdhgfv 6y ago
    Man, this is just begging for parallelization.
    - ggcdn 6y ago
      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.
  - jatone 6y ago
    thats just a shitty program lol
    - ggcdn 6y ago
      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.
- jcelerier 6y ago
  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.
sedatk 6y ago
Docker is a thing now, though.
daxfohl 6y ago
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.
bob1029 6y ago
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...
rasz 6y ago
Stop using Python for time critical applications ;-)

djd20 6y ago

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

hddherman 6y ago

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.

Theodores 6y ago
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.
- throwaway_pdp09 6y ago
  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.
  - tbrock 6y ago
    Anything JavaScript for example is single threaded for the most part. Also something like linking is typically in parallelized.
    - jatone 6y ago
      thats not the compilation process. that's just javascript. the compilation definitely has parallelism.
      - tbrock 6y ago
        You’d be surprised...
  - chitza 6y ago
    Most web development toolchains depend on Node.js, which compiles on a single core.
    - kohtatsu 6y ago
      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-single-threaded-7ea59bcc8d64 https://medium.com/better-programming/is-node-js-really-sing...
    - oppositelock 6y ago
      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.
    - jatone 6y ago
      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.
- jatone 6y ago
  fix your compilation process. there are few long running workloads that don't benefit from parallelism.
- rumanator 6y ago
  > 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?
  - user5994461 6y ago
    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.
    - jcelerier 6y ago
      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.
    - TazeTSchnitzel 6y ago
      > 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.
    - rumanator 6y ago
      > 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.
  - Theodores 6y ago
    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.
daxfohl 6y ago
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.

GhostVII 6y ago

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

vbezhenar 6y ago
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.

s9w 6y ago

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

dannyw 6y ago

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.

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

grecy 6y ago

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

ggcdn 6y ago
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.
- dvfjsdhgfv 6y ago
  Man, this is just begging for parallelization.
  - ggcdn 6y ago
    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.
- jatone 6y ago
  thats just a shitty program lol
  - ggcdn 6y ago
    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.
jcelerier 6y ago
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.

sedatk 6y ago

Docker is a thing now, though.

daxfohl 6y ago

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.

bob1029 6y ago

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

rasz 6y ago

Stop using Python for time critical applications ;-)