News Apple confirms switch to Arm-based architecture

Note that both of these are a result of "shove eleventy billion cores at a task you wrote/rewrote specifically to target those cores in massive parallel". A situation that does not hold for use in consumer devices: even if we ignore all existing OS X applications built for x86 under the assumption Apple will simply tell you to shove it if you ever want to run legacy code beyond a year or two after the transition (i.e. what they did last time they moved arch), then we're still stuck with the issue that after a decade and a half of dual-core x86 CPUs, a decade of quad (or more) cores, and easily a decade of multi-core CPUs being the norm (including on consoles, for those who love to blame them as 'holding PCs back'), software continues to be largely single threaded with very diminishing returns to the parts that are threaded. Because software on a consumer device is almost entirely software that you can't just point at a big dataset and wander off for a few hours, or have tens to hundreds of people using simultaneously, but instead is software that interacts with the user to perform serial tasks, i.e. it's all Amdahl's Law scaling. To achieve Gustafson's Law scaling requires both a task that can be expanded to fit the available resources (e.g. adding more cores will not making opening a folder any faster, only allow you to open more folders at the same time) and the ability to feed your CPU with the additional data to perform more tasks at once (why so much focus on HPC is in memory bandwidth and high-speed interconnects).
Notable exceptions on desktop machines are CPU rendering (mostly being offloaded to GPU now, 'cuz it's faster), and video encoding (for real-time like streaming this gets shoved to FFBs to minimise any CPU or GPU impact, but a factor for offline encoding).
The upshot being that for perceptually equivalent performance in existing tasks, you can't just drop in 4/8/etc ARM cores for every x86 core, even if you can convince every developer for your platform to re-write their software for both a new CPU arch and in massive parallel.

 

Dodging propriety: A multi-thousand device rollout (not sure what the contract figure was, but easily into 8 figures) to replace the high-core-count dual-socket workstations, because the 'back office' 4-core single-socket machines were consistently running rings around them in actual day-to-day performance rather than benchmarks. Nobody has asked to retain their HCC boxes, nobody has asked for their HCC boxes back or new (single CPU or otherwise) HCC boxes to be deployed as special orders. Install base covers a pretty good swathe of tasks from operational use to web dev to app dev to video production (admittedly most of the heavy lifting there is offloaded to dedicated broadcast hardware) to HPC dev/test to financial operations. So in my professional experience, real-world tasks that take advantage of high core counts are few and far between for boxes-that-sit-under-the-desk.
We also trialed each generation of not-iPad ARM devices, from the original WinRT series onwards (and 'onwards' today if you catch my drift). They all end up in the bin within a few days. Cheap is no good if everyone hates using them so much they'll pick a crappy remote instance in preference to even worse local performance (and half their stuff unable to even launch).

 

Most of those examples are "task multithreading" - as are most programs, things like GUI, some internal workloads (like each tab in browser), etc are split into each thread, but tasks themselves are pretty much serial - ie javascript engine in browser, or GCC, yes you can pass "-j16" to make, but that will only means that it will spawn up to 16 instances, if you need to compile one big lib that everything else uses, back to single core utilization. Can we rewrite those tasks to be multi threaded? Maybe - though as edzieba already said, most fall into Amdahl's Law. That and wast majority of programmers simply cant think in or code true multithreaded stuff.

 

Sadly, workstations need to run the software the users actually need to run, not some hypothetical software that should work the way chip manufacturers would like it to. Workstations do work after all, not run a decade old build of the Cinebench benchmark suite.

That's great for you. But if your task is linear, splitting it into discrete units just means those units have to sit idle waiting for the previous one to complete. Parallelism gains from a task that is only a small fraction parallel is nowhere close to a linear core scaling (e.g. if a task is only 50% parallel, then the best speedup you can ever hope for no matter how many cores you have is 2x).

Either way, we'll see if this latest iteration of "this time, ARM for client computing won't suck!" will turn out like every previous time: hyped as the best thing since sliced bread right up until devices actually end up in the hands of people that need to use them to do things.

 

The end user cares about execute time, not throughput per fixed unit time. If an 8-core device can only speed up a task 2x (limit for a 50% parallelism task), and a 2-core device can sped up a task 2x, then adding more cores does not produce any net benefit for the user. But if those 8 cores are individually slower, then you end up in the situation where the 8-core device's total task execution time is longer then the 2-core device, because the floor on total task execution time is the single threaded component of the task.
e.g. task is to boil an egg and butter 8 soldiers. You can split your buttering task into 8 'threads' that can be executed at once, but your boil-an-egg task cannot be accelerated no matter how many saucepans or eggs you have available. That then becomes the execution time floor for for the total task. If your task is only to boil a single egg, the capability to boil 8 eggs at once is of no practical value to you.

Same reason they buy LCC workstations: people spec and purchase workstations to the tasks they perform, or they end up paying more for a slower box.

The proof is that ARM on the desktop has flopped hard, repeatedly. Trying the same "oh, the cores are slower, but we have more of them and lower power!" over and over doesn't change things.

I'd say on the order of 5-7k on workstations, plus another 15-20k for general BO tasks (mostly office suite plus some more esoteric Excel & PP data source plugins). The BO guys were never on HCC machines, and those who ended up with them because of legacy or department-move wanted their LCC machines back! That's for UK which I have visibility of, RoW is probably an order of magnitude above that but the story I've heard from other regions is the same (as are purchasing changes which are global level).

If we limit that to comparable devices (i.e. laptops, desktop, and AIOs, no "oh, but people are buying iPad Pros now!") then I'll take that bet in terms of pure devices shipped volumes.

 

5 years?

Fine, I'll throw in a blinder of they'll start adding non ARM cores to the ARM cores in a mix and match design.

 

I'd expect Apple to sooner shutter their non-iOS lines before switching away from ARM if sales volumes drop (e.g. the death of the Macbook in the face of the Macbook Air). Maybe leaving the Mac Pro as-is for another 6-7 years untouched like with the last Mac Pro, and slowly losing lines as they go (I could see the Macbook and iMac lines being pared down to a single model each, and the Mac Mini just vanishing again).