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"?
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.
It's totally spoiled me.
8C/16HT or nothing for me now ;).
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.
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.
An interesting item came up recently. On Windows 10 there's a problem with highly parallel builds that is down to the fact that process exit cleanup is serialized inside the GDI on a lock that also needs to be taken during message input. Combine that with a build that splits things out into lots of compilation units that are all built in parallel using a process each, and fun ensues.
Ironically, it means that during the build you are not able to get stuck into anything else with a GUI. (-:
* https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and... (https://news.ycombinator.com/item?id=14733829)
Have you tried the GNU Gold linker? It's makes those serialized linking steps very fast and even supports concurrent linking :)
5 years ago I'd have struggled to get that out of a desktop. Today, my laptop handles that, barely breaking a sweat.
>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.
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).
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).
This probably increased CPU usage, but did it really reduce compilation times? I would imagine that any gains from parallelizing function compile times would be eliminated by having to process the header files over and over again. Not to mention the time cost of doing the splitting.
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).
Used to be Java chat apps and IDEs (Eclipse, IntelliJ) were considered slow and bloated.
They're practically fleet footed compared to the new breed of web apps.
As much as I love Slack, Visual Studio Code and Atom my maxed out MacBook Pro is at 50-100% CPU and paging into swap with all three open.
If I send a few GIFs in Slack - temps hit 99C (never 100 for some reason) and my laptop sounds like a mini hovercraft.
It's a little disheartening and really has me missing those big old Mac Pros which were silent no matter the task.
JavaScript and the resulting apps are certainly enjoyable to code and use but damn does something need to change in terms of resource utilization.
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.
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.
What happens if you close background browser tabs? :b
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.
Funnily enough someone correct me if I'm wrong but these are almost entirely ancient single core code.
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
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.