Also, AMD is only recently been a performance front runner - they might not hold on to that for long. In the short term it doesn't make sense to jump ship.
For for general computation/ecosystems or for generation/device specific ventures (e.g. Consoles) it makes sense to turn with the tides.
It's in Apple's history to be able to move on from hardware. It's also in their history to make the wrong choices, necessitating the move.
Apple's relationship with Intel is pretty rocky now. Intel fumbled the i9, their Xeon chips aren't keeping up with AMD's workstation offerings, and their efforts to build a cellular modem chip utterly failed, leaving Apple at the mercy of Qualcomm for that part.
I'm sure Apple will cut loose on Intel as soon as they can. They're probably tired of the bullshit.
Yes, but I think the bigger picture, Apple needed Intel's iPhone modem for another year. May not be worth to damage the relationship, not to mention the design were likely finalise some time ago.
I would not be surprised if the Sale of Modem Business to Apple will include agreement to keep Intel CPU on Mac. ( For the time being )
And I am sure AMD should be aiming EPYC at the Datacenter usage of Apple, which is huge in itself, rather then the market of Mac Pro. Although Apple using AMD on Mac would be a pretty big statement to the rest of the market.
And the successors to Cascade Lake seem to switch to the LGA4189 socket to support 8 memory channels (Cooper Lake and Ice Lake), so I wouldn't expect any upgrades on LGA3647.
The good news is that the next generation Mac Pro will have a ton of extra memory bandwidth.
However, Zen 2 Threadripper would likely be a better fit for a workstation such as Mac Pro as it will (most likely) have higher clock speeds. The current Threadripper lineup doesn't support more than 256 GB RAM, though. I don't know whether the new Threadripper will support RDIMM/LRDIMM to compete with Xeon-W on memory capacity.
What if the high-end chip was ARM? It's not just about raw speed, it's about how much performance you can squeeze out of a particular thermal envelope, or compute per watt. If ARM offers 2x the performance per watt, doesn't matter what Intel's chips do with hypothetically unlimited power.
The only company that has the rights to do both ARMv8 and amd64 is.. AMD :)
It might be more feasible now, except in the last ~5-10 years there's been a push to make many PC apps x86_64 only (e.g. Ubuntu dropping i386 support), so the benefit isn't quite as wide any more.
From 2017 https://arstechnica.com/information-technology/2017/06/intel...
Extremely unlikely, if only because x86-64's memory model is much stronger than ARM's. Emulating that on ARM would be a performance disaster.
Apple could have the internals of A14 or A15 have x86's memory model, but that's non-trivial changes and may have too much impact on their ARM performance to justify it. Seems far more likely we'd just see a Macbook that's just straight ARM with x86 code just not supported at all.
> What if the high-end chip was ARM? It's not just about raw speed, it's about how much performance you can squeeze out of a particular thermal envelope, or compute per watt. If ARM offers 2x the performance per watt, doesn't matter what Intel's chips do with hypothetically unlimited power.
For workstations it's almost entirely about raw speed. The power cost is a rounding error compared to the salary of the person using it that's now spending more time waiting on things and less time getting work done.
https://www.asrock.com/mb/AMD/X570%20Taichi/#Specification Supports an add-in card (connector). It's coming more generally since Intel dropped the licensing fees for TB. But yeah, only a few AMD boards do it (without hacks).
We'll know for sure when the product is actually out and we have independent benchmarks, but at this point you're just making things up and stating them as facts.
That aside Epyc was already ahead on real high-end workloads like povray or NAMD ( http://www.ks.uiuc.edu/Research/namd/ ). Epyc also puts up top numbers on compilation performance and OpenSSL. So it already isn't as black & white as you're pretending anyway. MySQL/DMBS is not the only server workload that exists, even though it may be the only workload you specifically care about.
DBMSs are normally IO constrained or memory constrained, or lack-of-index index constrained or query-plan-gone-mental-from-cardinality-misestimation constrained, or others. It's very unusual IME to find one that is CPU constrained. Bringing up DBs in this context is peculiar to say the least.
I've literally just lost 20 hours trying to debug a query that intermittently ran many times too slow. It was a memory misconfiguration. Extra CPU is at best a bandage over these kinds of problems, at worst, just wasted.