6 ms·

How do people with many CPU cores find it helps their day to day, excluding people who run VMs, or do highly parallelisable things as their 80% core job loop (i

by SCdF 9y ago

How do people with many CPU cores find it helps their day to day, excluding people who run VMs, or do highly parallelisable things as their 80% core job loop (ie you run some form of data.paralellMap(awesomeness) all day)? Does it help with general responsiveness? Do many apps / processes parallalise nicely? Or is it more "Everything is 99% idle until I need to run that Photoshop filter, and then it does it really fast"?

nicktelford 9y ago
As a programmer, being able to run non-trvial parallel builds (e.g. compiling large Scala projects), whilst keeping the machine quite usable for other things is pretty awesome. 5 years ago I'd have struggled to get that out of a desktop. Today, my laptop handles that, barely breaking a sweat.
daveguy 9y ago
Being able to do big jobs in the background and still use your computer effectively. Run 3 VMs for different platforms and still have a functioning computer. There is a lot of task level parallelization that many cores helps with regardless if any one is optimized. That said, a lot of software is multithreaded these days.
- metalliqaz 9y ago
  Running 4 OSes at once (host + 3 VMs) I would hope you have a very quick SSD and lots of RAM, otherwise that CPU isn't going to help much.
  - Retric 9y ago
    64GB of ram is surprisingly affordable assuming you want to run a few VM's on one box. You can also give each VM it's own SSD without spending crazy money. AKA it's far less than the cost of 3 mid range PC's.
colanderman 9y ago
For me, it's both the "really fast Photoshop filter" (or, in my case, static analyzer run), and responsiveness when I do e.g. a build that I've restricted to use all but one core. Otherwise yes, the cores just sit there idle.
Klathmon 9y ago
I have the 4930K processor (6 core, 12 thread processor from 2013-ish). It's painful trying to do the same workflow I do on my desktop on a 2-core laptop. Because I have the power, i've started really using the ability to multitask to it's fullest. Having multiple VMs running, being able to run the full suite of unit-tests on every save, run linters/static analysis as often as it can, etc... Builds don't slow me down, npm-install goes much faster and doesn't really cause any choppiness, I basically don't need to worry about CPU efficiency in any of my tools. I feel it's more than paid for itself over the past 4 years (it was only like a few hundred more than the 4 core machine) in time saved alone, ignoring the reduction in frustration or distraction from having to wait on things to finish or wait for the stutters and stalls to stop.
- metalliqaz 9y ago
  It seems like the CPU could only get you so far in the setup you describe. I assume you have no spinning platters in your desktop, and are using 1 or more SSDs? IO-bound workloads are very common in what you're describing.
  - Klathmon 9y ago
    Yeah I've got a PCIe SSD that I don't remember the exact details on right now, and I setup a ramdisk to build from a while ago but never really benchmarked it to see if it was actually making a difference. Still, you'd be surprised how much having the extra CPU headroom helps there. A lot is IO bound, but at least with the extra CPU cores the PC is still responsive and able to do other things while waiting (for the most part). When you get CPU bound, it starts to hurt. Back when I built it I looked at the total cost and did some math on how long I thought it would last, and how much time it might save me and figured out that even if I really went all out, if it made me even a few percent more productive it'd be more than worth it, so I kind of went nuts on it, and I'm very happy with my decision.
- noir_lord 9y ago
  Same with the Ryzen I have at work, my old i5 desktop feels different, micropauses I wasn't even aware of are an issue and my laptop is even worse. It's totally spoiled me. 8C/16HT or nothing for me now ;).
fulafel 9y ago
Not a lot. Most software isn't very parallel. I think 2 fast cores would be the sweet spot for most people, for the foreseeable future. I think a question like this will get very biased answers, since most people aren't very inclined to post "paid a lot, don't really use it" and rather stay mum. BTW taken out of context, "people with many CPU cores" would mostly consist of 8-core Android phone owners. They also do little with all those cores.
- Retric 9y ago
  I regularly see 8 cores over 50% utilization. So sure 90% of the time you don't really need it, but a lot more things are parallel now than you might think. Consider, if your PC is going to last 3+ years, and you average ~40 hours a week on it then the most demanding 1% is still 48+ hours.
  - cat199 9y ago
    > I regularly see 8 cores over 50% utilization. What happens if you close background browser tabs? :b
- blattimwind 9y ago
  Standard office computer here is a quad core (AMD APU), and it actually makes quite a bunch of stuff faster (e.g. conversion of scanned documents) compared to the previous-generation dual cores.
- jhasse 9y ago
  It was shown that for most games nowadays 2 cores will result in micro-stutter. For example the Pentium G4560 (2x 3.50GHz) has pretty good average FPS, but if you look at the 99th percentile, it's worse than similar priced quad cores.
hajile 9y ago
64 instead of 24 pcie lanes is huge too
rwmj 9y ago
I have a 2 sockets x 8 cores (16 real cores) Xeon desktop machine from last year. It's very fast. But to make it useful for compilation, I had to make a lot of alterations to our software and build systems to ensure we were maximally parallelizing builds. This included splitting up C programs into separate C files almost comically fine-grained. I was literally using ‘wc -l *.c’ and trying to even up the size of the files. Eventually you hit Amdahl's law: Some parts of the build (I'm looking at you, autoconf configure scripts) simply cannot be parallelized and they slow the whole system down. The other thing it does well is virtualization, but that tends to be limited by RAM and disk space. The machine has 64 GB of RAM so it can run plenty of VMs, but I had to install more disks so I could store those VMs. It now has 4 SSDs and 3 hard drives, and managing the space across those is a bit painful (with LVM).
- blattimwind 9y ago
  > Eventually you hit Amdahl's law: Some parts of the build (I'm looking at you, autoconf configure scripts) simply cannot be parallelized and they slow the whole system down. Linking a large C/C++ project can take some (a lot of) time as well. Linking is of course in general a rather difficult to parallelize problem, except if there is no linking (e.g. because the runtime links everything at every application start cough).
  - rwmj 9y ago
    Absolutely yes, linking was another unsolvable problem when I was parallelizing the builds. As was odd stuff like building documentation, building Perl bindings and a few other things that were inherently serial.
  - cesarb 9y ago
    Does partial linking (ld -r) allow one to parallelize linking? The Linux kernel does that on its build system, though I don't know if it's for performance reasons.
  - jhasse 9y ago
    Have you tried GNU Gold? It's A LOT faster and it should even support concurrent linking.
jdietrich 9y ago
A reasonably large proportion of workstation-type tasks do parallelise very well. The example I'm most familiar with is professional audio. A typical audio project will include hundreds of plugin instances, each with their own thread. Performance for this workload scales more-or-less linearly with core count. As I understand it, many VFX and video editing workloads are also highly parallelisable. >Or is it more "Everything is 99% idle until I need to run that Photoshop filter, and then it does it really fast"? Using all your cores all the time doesn't really matter. A Digital Audio Workstation is very much either/or in terms of CPU use - as soon as you stop playback, your CPU usage drops to idle. If you run out of CPU overhead during playback then everything grinds to a halt, which can be absolutely disastrous when you've only got 3 milliseconds of buffered audio. We want enough FLOPS to cope with our normal workloads, plus a substantial overhead to cope with spikes.
musha68k 9y ago
I guess I'm not the only one having a problem with development on our low/slow core portable computers (MBP in my case). Just the other day a friend of mine voiced his dismay over the fact that "there was a point in time - a sweet spot seemingly - not too long ago, where we could work effortlessly on an (underpowered) Macbook Air / Macbook". I'd have to echo that as the compounding tax on single / multi core CPU resources has grown substantially over the last couple of years - both through a "renaissance" of more compilation heavy toolchains on one side as well as the (dare I say it?) "microservices as a monolith" effect through explosive adoption of container based "architectures" on the other (docker-compose anyone?). After more than a dozen very happy years on almost as many Macs I'll seriously get back to developing on a powerful Linux workstation – looking forward to less computational overhead over Docker on both wetware/hardware alone.. I'm really just waiting for Threadripper to make that happen. My new iPad Pro will be there for administrivia / communication / ideas (very much looking forward to the highly pencil informed iOS 11) – of course I'll also keep my MBP to get it out of the drawer for the occasional asset manipulation with Affinity Designer (the 2 core Broadwell with 16GB RAM should last for many years for those kinds of tasks).
- striking 9y ago
  Something you might want to try is hosting a Kubernetes server on some more powerful machine (like a VPS or something at home) to run some of the Docker services you won't actively be developing against.
  - musha68k 9y ago
    Thanks for the idea :) I actually did something along those lines - completely switched to emacs within a tmux session on some large EC2 instances but meanwhile optimized my workflow (introduced more isolated TDD) so that performance is bearable enough on my local machine..
- jorvi 9y ago
  That sweet spot has nothing to do with compilation or Docker, and everything with the rise of Electron. Before, an app was built with native UI libraries, running on Python with core elements in C++ for speed. After, a simple app (like Slack or WhatsApp desktop) will eat 300-500mb, use 1-10% CPU and chew through your battery alive.
intoverflow2 9y ago
> Photoshop filter Funnily enough someone correct me if I'm wrong but these are almost entirely ancient single core code.
- fooker 9y ago
  No, they are very easily parallelized and even use the available GPU for the last dozen years.
  - sqeaky 9y ago
    Sean Parent does love squeezing all the performance out of even the tiniest devices. There is a video of him loading the largest (he knew of at the time) JPG on an iPad 1. The image is several gb and it works pretty well on a machine with much smaller RAM. I think this is the talk: https://www.youtube.com/watch?v=giNtMitSdfQ https://www.youtube.com/watch?v=giNtMitSdfQ If not, I am watching and will try to post it later. EDIT - I don't think that is the right talk, but its still good.
IanCal 9y ago
I do a lot of analysis that often boils down to "do X a hundred million times". Getting a 6 core machine setup earlier this year didn't make a difference for most things but when I want to run something like that (most days) it makes a huge difference. Bringing an almost all day task to an hour hugely changes the workflow.
shmerl 9y ago
Building stuff from source takes less time.
sqeaky 9y ago
Build Time! I will pay a great deal of money to reduce my build times. Building is readily parallelizable and with a good enough build scripts and system design there are several smaller linking steps instead of one huge serialized one at the end. On my current system building the code I care about only takes about 2 minutes, about 5MLOCs of C++. Anything more than 10 seconds is enough to get stuck in the time waste that is Reddit... or HN... I am getting back to work now, my build is likely done.
- musha68k 9y ago
  I now know why they sell so many of those "fidget spinners" these days – it's all the core-starved developers like myself not wanting to get stuck on HN while waiting for their builds to finish ;D
- jhasse 9y ago
  > and system design there are several smaller linking steps instead of one huge serialized one at the end. Have you tried the GNU Gold linker? It's makes those serialized linking steps very fast and even supports concurrent linking :)
  - sqeaky 9y ago
    Yes, and it took about 5% off my link step. It was nice, but no a fundamental game changer. I suspect someone who didn't already a bunch of smaller link steps would benefit more.
    - starsinspace 9y ago
      Gold also supports incremental linking [0], where it basically modifies the existing binary by only replacing the changed parts of it. I've never used it myself so I don't know how well it works, but you might want to look into it if you haven't already. [0] https://gcc.gnu.org/wiki/GoldIncrementalLinking https://gcc.gnu.org/wiki/GoldIncrementalLinking
      - 9y ago
sliverstorm 9y ago
Has helped a lot with my photo tools. Probably any time you're chewing a lot of data, of any kind. But Word, Chrome, and PuTTy don't seem to care :)

by SCdF 9y ago

nicktelford 9y ago

As a programmer, being able to run non-trvial parallel builds (e.g. compiling large Scala projects), whilst keeping the machine quite usable for other things is pretty awesome. 5 years ago I'd have struggled to get that out of a desktop. Today, my laptop handles that, barely breaking a sweat.

daveguy 9y ago

Being able to do big jobs in the background and still use your computer effectively. Run 3 VMs for different platforms and still have a functioning computer. There is a lot of task level parallelization that many cores helps with regardless if any one is optimized. That said, a lot of software is multithreaded these days.

metalliqaz 9y ago
Running 4 OSes at once (host + 3 VMs) I would hope you have a very quick SSD and lots of RAM, otherwise that CPU isn't going to help much.
- Retric 9y ago
  64GB of ram is surprisingly affordable assuming you want to run a few VM's on one box. You can also give each VM it's own SSD without spending crazy money. AKA it's far less than the cost of 3 mid range PC's.

colanderman 9y ago

For me, it's both the "really fast Photoshop filter" (or, in my case, static analyzer run), and responsiveness when I do e.g. a build that I've restricted to use all but one core. Otherwise yes, the cores just sit there idle.

Klathmon 9y ago

I have the 4930K processor (6 core, 12 thread processor from 2013-ish). It's painful trying to do the same workflow I do on my desktop on a 2-core laptop. Because I have the power, i've started really using the ability to multitask to it's fullest. Having multiple VMs running, being able to run the full suite of unit-tests on every save, run linters/static analysis as often as it can, etc... Builds don't slow me down, npm-install goes much faster and doesn't really cause any choppiness, I basically don't need to worry about CPU efficiency in any of my tools. I feel it's more than paid for itself over the past 4 years (it was only like a few hundred more than the 4 core machine) in time saved alone, ignoring the reduction in frustration or distraction from having to wait on things to finish or wait for the stutters and stalls to stop.

metalliqaz 9y ago
It seems like the CPU could only get you so far in the setup you describe. I assume you have no spinning platters in your desktop, and are using 1 or more SSDs? IO-bound workloads are very common in what you're describing.
- Klathmon 9y ago
  Yeah I've got a PCIe SSD that I don't remember the exact details on right now, and I setup a ramdisk to build from a while ago but never really benchmarked it to see if it was actually making a difference. Still, you'd be surprised how much having the extra CPU headroom helps there. A lot is IO bound, but at least with the extra CPU cores the PC is still responsive and able to do other things while waiting (for the most part). When you get CPU bound, it starts to hurt. Back when I built it I looked at the total cost and did some math on how long I thought it would last, and how much time it might save me and figured out that even if I really went all out, if it made me even a few percent more productive it'd be more than worth it, so I kind of went nuts on it, and I'm very happy with my decision.
noir_lord 9y ago
Same with the Ryzen I have at work, my old i5 desktop feels different, micropauses I wasn't even aware of are an issue and my laptop is even worse. It's totally spoiled me. 8C/16HT or nothing for me now ;).

fulafel 9y ago

Not a lot. Most software isn't very parallel. I think 2 fast cores would be the sweet spot for most people, for the foreseeable future. I think a question like this will get very biased answers, since most people aren't very inclined to post "paid a lot, don't really use it" and rather stay mum. BTW taken out of context, "people with many CPU cores" would mostly consist of 8-core Android phone owners. They also do little with all those cores.

Retric 9y ago
I regularly see 8 cores over 50% utilization. So sure 90% of the time you don't really need it, but a lot more things are parallel now than you might think. Consider, if your PC is going to last 3+ years, and you average ~40 hours a week on it then the most demanding 1% is still 48+ hours.
- cat199 9y ago
  > I regularly see 8 cores over 50% utilization. What happens if you close background browser tabs? :b
blattimwind 9y ago
Standard office computer here is a quad core (AMD APU), and it actually makes quite a bunch of stuff faster (e.g. conversion of scanned documents) compared to the previous-generation dual cores.
jhasse 9y ago
It was shown that for most games nowadays 2 cores will result in micro-stutter. For example the Pentium G4560 (2x 3.50GHz) has pretty good average FPS, but if you look at the 99th percentile, it's worse than similar priced quad cores.

hajile 9y ago

64 instead of 24 pcie lanes is huge too

rwmj 9y ago

I have a 2 sockets x 8 cores (16 real cores) Xeon desktop machine from last year. It's very fast. But to make it useful for compilation, I had to make a lot of alterations to our software and build systems to ensure we were maximally parallelizing builds. This included splitting up C programs into separate C files almost comically fine-grained. I was literally using ‘wc -l *.c’ and trying to even up the size of the files. Eventually you hit Amdahl's law: Some parts of the build (I'm looking at you, autoconf configure scripts) simply cannot be parallelized and they slow the whole system down. The other thing it does well is virtualization, but that tends to be limited by RAM and disk space. The machine has 64 GB of RAM so it can run plenty of VMs, but I had to install more disks so I could store those VMs. It now has 4 SSDs and 3 hard drives, and managing the space across those is a bit painful (with LVM).

blattimwind 9y ago
> Eventually you hit Amdahl's law: Some parts of the build (I'm looking at you, autoconf configure scripts) simply cannot be parallelized and they slow the whole system down. Linking a large C/C++ project can take some (a lot of) time as well. Linking is of course in general a rather difficult to parallelize problem, except if there is no linking (e.g. because the runtime links everything at every application start cough).
- rwmj 9y ago
  Absolutely yes, linking was another unsolvable problem when I was parallelizing the builds. As was odd stuff like building documentation, building Perl bindings and a few other things that were inherently serial.
- cesarb 9y ago
  Does partial linking (ld -r) allow one to parallelize linking? The Linux kernel does that on its build system, though I don't know if it's for performance reasons.
- jhasse 9y ago
  Have you tried GNU Gold? It's A LOT faster and it should even support concurrent linking.

jdietrich 9y ago

A reasonably large proportion of workstation-type tasks do parallelise very well. The example I'm most familiar with is professional audio. A typical audio project will include hundreds of plugin instances, each with their own thread. Performance for this workload scales more-or-less linearly with core count. As I understand it, many VFX and video editing workloads are also highly parallelisable. >Or is it more "Everything is 99% idle until I need to run that Photoshop filter, and then it does it really fast"? Using all your cores all the time doesn't really matter. A Digital Audio Workstation is very much either/or in terms of CPU use - as soon as you stop playback, your CPU usage drops to idle. If you run out of CPU overhead during playback then everything grinds to a halt, which can be absolutely disastrous when you've only got 3 milliseconds of buffered audio. We want enough FLOPS to cope with our normal workloads, plus a substantial overhead to cope with spikes.

musha68k 9y ago

I guess I'm not the only one having a problem with development on our low/slow core portable computers (MBP in my case). Just the other day a friend of mine voiced his dismay over the fact that "there was a point in time - a sweet spot seemingly - not too long ago, where we could work effortlessly on an (underpowered) Macbook Air / Macbook". I'd have to echo that as the compounding tax on single / multi core CPU resources has grown substantially over the last couple of years - both through a "renaissance" of more compilation heavy toolchains on one side as well as the (dare I say it?) "microservices as a monolith" effect through explosive adoption of container based "architectures" on the other (docker-compose anyone?). After more than a dozen very happy years on almost as many Macs I'll seriously get back to developing on a powerful Linux workstation – looking forward to less computational overhead over Docker on both wetware/hardware alone.. I'm really just waiting for Threadripper to make that happen. My new iPad Pro will be there for administrivia / communication / ideas (very much looking forward to the highly pencil informed iOS 11) – of course I'll also keep my MBP to get it out of the drawer for the occasional asset manipulation with Affinity Designer (the 2 core Broadwell with 16GB RAM should last for many years for those kinds of tasks).

striking 9y ago
Something you might want to try is hosting a Kubernetes server on some more powerful machine (like a VPS or something at home) to run some of the Docker services you won't actively be developing against.
- musha68k 9y ago
  Thanks for the idea :) I actually did something along those lines - completely switched to emacs within a tmux session on some large EC2 instances but meanwhile optimized my workflow (introduced more isolated TDD) so that performance is bearable enough on my local machine..
jorvi 9y ago
That sweet spot has nothing to do with compilation or Docker, and everything with the rise of Electron. Before, an app was built with native UI libraries, running on Python with core elements in C++ for speed. After, a simple app (like Slack or WhatsApp desktop) will eat 300-500mb, use 1-10% CPU and chew through your battery alive.

intoverflow2 9y ago

> Photoshop filter Funnily enough someone correct me if I'm wrong but these are almost entirely ancient single core code.

fooker 9y ago
No, they are very easily parallelized and even use the available GPU for the last dozen years.
- sqeaky 9y ago
  Sean Parent does love squeezing all the performance out of even the tiniest devices. There is a video of him loading the largest (he knew of at the time) JPG on an iPad 1. The image is several gb and it works pretty well on a machine with much smaller RAM. I think this is the talk: https://www.youtube.com/watch?v=giNtMitSdfQ https://www.youtube.com/watch?v=giNtMitSdfQ If not, I am watching and will try to post it later. EDIT - I don't think that is the right talk, but its still good.

IanCal 9y ago

I do a lot of analysis that often boils down to "do X a hundred million times". Getting a 6 core machine setup earlier this year didn't make a difference for most things but when I want to run something like that (most days) it makes a huge difference. Bringing an almost all day task to an hour hugely changes the workflow.

shmerl 9y ago

Building stuff from source takes less time.

sqeaky 9y ago

Build Time! I will pay a great deal of money to reduce my build times. Building is readily parallelizable and with a good enough build scripts and system design there are several smaller linking steps instead of one huge serialized one at the end. On my current system building the code I care about only takes about 2 minutes, about 5MLOCs of C++. Anything more than 10 seconds is enough to get stuck in the time waste that is Reddit... or HN... I am getting back to work now, my build is likely done.

musha68k 9y ago
I now know why they sell so many of those "fidget spinners" these days – it's all the core-starved developers like myself not wanting to get stuck on HN while waiting for their builds to finish ;D
jhasse 9y ago
> and system design there are several smaller linking steps instead of one huge serialized one at the end. Have you tried the GNU Gold linker? It's makes those serialized linking steps very fast and even supports concurrent linking :)
- sqeaky 9y ago
  Yes, and it took about 5% off my link step. It was nice, but no a fundamental game changer. I suspect someone who didn't already a bunch of smaller link steps would benefit more.
  - starsinspace 9y ago
    Gold also supports incremental linking [0], where it basically modifies the existing binary by only replacing the changed parts of it. I've never used it myself so I don't know how well it works, but you might want to look into it if you haven't already. [0] https://gcc.gnu.org/wiki/GoldIncrementalLinking https://gcc.gnu.org/wiki/GoldIncrementalLinking
    - 9y ago

sliverstorm 9y ago

Has helped a lot with my photo tools. Probably any time you're chewing a lot of data, of any kind. But Word, Chrome, and PuTTy don't seem to care :)