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

 

Not sure if you're aware or have a need, but I thought I'd shout out Blip, as it's particularly useful for 'air dropping' from/to non-ios phones, in case you'd feel like you're missing out on this feature.

 

Well… there’s a necro… Not the worst we’ve seen around here, but still… I had a jolly little chuckle reading through all this .

Turns out that Apple did come along with an ARM chip that delivered both stellar performance and battery life. There were some initial hiccups and incompatibilities, but on the whole the Rosetta2 translation layer was a resounding success. A few more issues for developers like me than there were for “normal” people, but there was usually a workaround. In fact I’ve had to unpick a hell of a lot of those workarounds in our dev environment setup at work, because they haven’t been necessary in years.

And then Microsoft followed suit with Qualcomm and… er… yeah… it went… “well”. I mean… the products launched didn’t they? That’s gotta count as “going well” in anyone’s book

I’m sorry to be the one to tell you this, but… you’re replying to a user who hasn’t been online in nearly 4 years in a thread that’s 5 years old…

 

The dev kit didn't.

Also this is/was [minimum] MS' second attempt at getting windows to run on ARM... remember Windows RT?

 

My friend, I remember Windows CE running on both ARM and MIPS hardware .

I had a Compaq iPAQ (yes iPAQ, not iPad) running WinCE some quarter of a century ago. Later I had a couple of HTC “smartphones” running WinCE in its “Windows Mobile” guise; first the HTC TyTN II with its slide-out keyboard, and later the HTC Touch Diamond.

The Touch Diamond was a neat phone, shame it got pickpocketed when I was in a pub.

 

My last two cars were running WinCE and Arm, you could even get up a proper windows GUI on one doing some cheat codes so you could argue they were quite successful with it, just not where you expect.

 

Found it!

Well... Found a photo of it, the actual device I had is long gone...

Compaq iPAQ 3630: