Apple CPU Gains Grind to a Halt and the Future Looks Dim(semianalysis.com) |
Apple CPU Gains Grind to a Halt and the Future Looks Dim(semianalysis.com) |
I think its much more likely that the effects of COVID measures are just now being felt by many corporations both in the supply chain as well as product development.
I don't think this is event remotely correct to begin with (Apple advantage was in mips-per-watt. AMD wipes the floor with them in performance department, but also uses more power).
And the author doesn't seem to understand that the architecture was mostly created by ARM.
With a start like that, I am not sure if I should read the rest.
What do you think this means?
Are we talking single or multi-core? I don't think they are far in single-thread performance.
In broad strokes, a computationally heavy task that would be set up during the evening and be ready the next morning on a high end desktop wouldn't be ready on an M1 for a week.
You cannot do everything in-house and think you can always be better than every other company in the world. One bad year in one department and your competitors will eat your market share.
That doesn't seem to be slowing down sales of laptops and minis, or phones. Memory is tightly packed, but that's for SoC size - the processor tile talks to the memory via a DDR4 bus on the SoC board and can easily talk to memory across the motherboard. I'd bet on that for future ARM-based MacPro's and upgradable iMacs.
Making a socketed M1/M1X/M2/M2X is a matter of packaging, IF Apple wants it: they are not in the general CPU market. There may be some market in upgrading CPUs in the MacPro's, but I doubt it'd justify the investment.
> that fully supports only one OS
That's not really a problem for Apple - they chose to base all their offerings on a portable OS for a reason. The current system we call MacOS was ported to run on 68K, x86 (under NeXT for 32-bit, under Apple 64-bit), HP-PA, SPARC, PPC, ARM (both 32 - as iOS - and 64-bit).
All in all, the roadmap for beefier M's is clear - a wider backend, ISA extensions for common workloads (one of the reasons the M1 performs so well), and a larger reorder buffer (another reason the M1 performs so well) to keep the wider backend well fed.
It did and that's why Apple themselves had to backtrack when the Mini with the soldered RAM and SSD failed to sell as much as anticipated. (That's why the next version had swappable RAM, and not soldered).
All things being equal, people will always choose the device that is more easy to repair and upgradeable.
Apple has 2 things going for the M1 devices:
- They are priced cheaper to make the hardware attractive.
- They offer similar performance to AMD CPUs (with the advantage of lower power consumption.)
Both these factors help overcome the obvious deficiency - that the hardware is not upgradeable or repairable and the system software is limited to one OS. If Apple's ARM processors cannot keep up with AMD / Intel / other ARM cpus, both hardware and software limitations become glaring. And Apple is left with only the price advantage. (And we all know that Apple doesn't play that game as it isn't interested in the low margins market).
I'm sure Qualcomm & Co. would happily help them out if they're in a bind with their own design.
Now they have enough money to do that more than just 20 years, but nothing lasts forever.
Apple doesn't use AMD and there is no supported AMD machine that can run macOS.
I like my AMD-based Linux box, but, if I want macOS, that's not going to solve my needs (it won't, for instance, run Xcode)
Javascript is still single core bound, and that's often a bottleneck for consumer computer use.
Though, if I'm not mistaken, I do believe that Web Workers is supported on all major browsers, including Safari. This allows the main JS thread (the one per tab) to spin up additional separate threads for other workloads. This page seems to confirm this: https://caniuse.com/webworkers
Here is an example to try out: https://codepen.io/prosetech/embed/qeqGQR? (source: [1]). When I tried it in chrome (default settings on linux) with a search range of 1 to 5,000,000, it took roughly 16 seconds and overall CPU usage was around 12%. Feel free to try it on an M1 (I'm genuinely curious, since comparable benchmarks are really hard to come by). This doesn't use the GPU at all, and is already CPU resource restricted, so I would expect it to fare well.
I'm sure the browser will handle some scheduling to limit 100% usage regardless of what the OS allows it.
So, it is I said before. That it seems a bit dishonest to exclusively focus on single core performance, as if that matters more than what the CPU can do when fully utilized. And, when fully utilized, the M1 is not remarkable in the slightest. It was a seriously misleading and dishonest marketing campaign. The only exception is, power consumption, which is pretty good. I find the idea of needing a lot of computing power, while also being limited by battery life, to be a contrived scenario. Wouldn't you be plugged in? Even the trains I've been to in recent memory have had power outlets.
With all that said, I think it's silly to consider javascript performance to be all that relevant. I hope this doesn't come across as a gatekeeping point of view. But when I talk about computing power, I don't really think about whether a web-page loads in 100 ms or 110 ms. But rather of machine learning tasks, photoshop filters. A software compilation. A blender render. Whether these things take 14 hours, or 1 hour. Which is what you can expect to be the difference in performance when fully utilizing a top end desktop GPU+CPU vs the M1. A practical difference of a "see you tomorrow morning", vs "see you in a week".
[1]: https://medium.com/young-coder/a-simple-introduction-to-web-...