The real question for me with all these AMD releases, what's Intel gonna release? It's surprising to me that Apple didn't announce an AMD based Mac Pro-- the chip Intel gave them must really be something. Too bad though because there could be a lot more of them (eventual Mac Pros) out there I'm guessing if they were using these Rome chips.
There's probably bit of hardware lot it with Intel chips. Since they control the hardware, Apple probably has invested quite a bit into hardware specific optimizations that won't readily port to AMD chipsets.
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.
Funnily enough the only "bespoke" Intel chip in recent times was Intel's own i7-8705G & i7-8809G used in the Hades Canyon NUC that replaced Intel's HD graphics with an AMD Vega M.
Which was an amazing chip. The Vega M + Intel cores combo delivered the graphics performance that Intel has been promising for years now. Would have loved to see a chip like that power the next few generations of ultrabooks, MBP's, etc.
>Intel provides financial incentives for manufacturers who build products around their chips.
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.
That usually involves advertising, but Apple has turned down those offers. Not even an "Intel inside" sticker.
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.
I think it'd really only be surprising if the Mac Pro ignored these chips when they were already available. At this point, though, the Mac Pro is shipping before Rome is available. The timing is just off. Current Xeons are faster than current Epyc's on average, so the choice today makes sense. Particularly if Apple wants to avoid NUMA in these machines. It wouldn't be unreasonable for a Mac Pro refresh in 2 years to switch to Epyc, though, if current trends continue to hold.
No, Rome is expected to officially launch in early Q3 (it's already shipping to hyperscalers) and the Mac Pro is expected to ship in September.
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.
The Mac Pro uses the LGA3647 socket, which I assume will give it some headroom for incremental upgrades in the next few years before a major overhaul is due. Intel already offers 112-thread part for that socket.
No, the 56C/112T Intel Xeon Platinum 9282 is a BGA part, it's not socketed. You can buy this niche product only as part of a server with liquid cooling.
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.
Given the JavaScript performance of the shipping units intended for mobile use, which is eclipsing the best of Intel's offerings, it might be possible that the A14 or A15 iteration actually surpasses Intel's chips at x86-64 code as well when run through a Rosetta-like compatibility layer.
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.
> it might be possible that the A14 or A15 iteration actually surpasses Intel's chips at x86-64 code as well when run through a Rosetta-like compatibility layer
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.
Most of the original x86_32 patents have now expired, that was sufficient to let Microsoft build the emulation layer for WoA.
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.
Apple, like all big vendors, is trapped by the mobile processors. There is still no way around Intel there. Until they are willing to get rid of Intel Chips in their whole lineup, they can't offer AMD chips in their desktop machines. For the same reason, AMD didn't gain dominance in the times the Opteron ran circles around the Intel chips.
People use Macs also to produce music and for this task the most important is single core performance. AMD is not great at this and it seems like the new line of CPUs could only get on par with Intel which isn't enough to convince professionals to move.
Intel chips are still significantly better than AMD for many common workloads. If you are running SpecCPU or Cinebench in production then AMD might be right for you; in all other cases I urge you to run your own realistic benchmarks before buying. Intel’s “response” to Rome came out in April. It’s a 28-core chip that costs $12k. The reason Intel doesn’t feel price pressure here is they are still way ahead in performance on real high-end workloads like DBMSs etc.
Rome is Zen 2. You have absolutely no clue whatsoever how it performs. It may still have the weaknesses of Zen 1, but it very well might not. AMD made a bunch of changes, including a complete overhaul of the memory system (no more NUMA).
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.
Don’t assume everyone suffers from the same ignorance that you suffer. The buyers in a position to get early samples of Rome are not paying retail prices on Intel.
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.
That used to be true for original EPYC but might not be true for Rome (outside AVX-512 workloads). IMO it's more due to continuous Apple + Intel collaboration and supply chain, AMD not being able to supply large market (they share TSMC with Apple for their CPUs), and overall unknown situation for AMD (will they stick with what they do now or abort?). If AMD just matches single thread performance of 9900k, there's not much point in switching. And Apple already uses their GPUs anyway, even if NVidia is still much better.
Does anyone have an idea how many different processors tapeouts are needed to create this line?
It seems reasonable to assume that 48-core chip is just 64-core chip with few defective cores. A lower clocked version is the same ship that high clocked that did not pass some test.
There are three tapeouts used for the entire desktop, HEDT, and server lineup combined. Everything uses the same 8 core CPU dies and there are two different I/O dies- a smaller one used for desktop (which doubles as the X570 chipset) and a big one for HEDT/server. There's also a separate 4 core + GPU die used for laptop parts.
This is correct for desktop and server. However, AMD hasn't said anything about the HEDT I/O die yet, as far as I know.
Assuming Zen 2-based Threadripper will still have quad channel memory and 64 PCIe lanes, AMD might go for a medium sized I/O die instead of disabling half of the large server I/O die. Or maybe the Threadripper volume is too low and a separate tapeout is not worth it.
I haven't seen a lot for Zen2 based Threadripper news since the end of May so maybe I missed how they are doing those chips like via the same 8 core chiplets as Zen2 or something larger. If their yields are really really good, maybe they are stacking 8 core chiplets for Rome and based on final yields on that determine what range will be offered as Zen2 TR HEDT to split 16 core Zen2 from Rome. Maybe at 16 cores, Zen2/Ryzen 9 is HEDT enough to compete?
If they are doing larger chiplets for Rome like 16 or 32 core but pairing up with Infinity Fabric for up to 64 cores, yields could also determine what becomes Zen2 TR with the weak chiplets becoming 8-32 core 92 chiplets), single CPU HEDT material? Or will they have a whole other solution here like limiting Zen2 TR to the same socket as previous gens to push upgrades vs a first gen TR user jumping to a Ryzen 3850X vs low end Rome?
This is true that they haven't actually confirmed that Threadripper is using the EPYC I/O die but I would be very surprised if it isn't. The entire idea behind Threadripper was to reuse as much EPYC tech as possible (in particular the physical socket) to keep NRE costs low because the HEDT market is so small.
Each of those smaller dies is 8 cpu cores. So 8x8 = 64. The 48-core one could either be 6 full-yield chiplets, or 8 partially defective ones with just 6 cores active. I'd guess it's 8 chiplets with 6 cores each just because that seems like it'd be more balanced, but I don't think we'll know for sure until someone de-lids a shipping one.
It depends on yield. If it's very high, you save money using only 6 chiplets. If it's not as great then using 8 lets you downbin the 64 core parts that were defective into the 48 core slot.
You can't do both in the same SKU because they have different performance, e.g. different amounts of L3 cache & memory bandwidth.
So at a 225w TDP I'd guess that part is going to be clocked in the 1.2 -1.5GHz range. Definitely a specialist part IMO because with only 8 channels of memory that's 1 channel per eight cores which is not a ton of bandwidth. So for workloads that largely stay in the (I assume) ample L3/L2 caches that part will rock. But for anything that needs a lot of bandwidth spread across cores (databases come to mind) it will probably struggle where the higher clocking 24 core or 32 core parts will probably chug on fine. This oddly seems like a case where the 48 core may still be a better buy even for similar workloads due to higher base clocks.
I think they're pointing out that many of the bottlenecks that make computers feel slow can't be fixed by throwing more cores at them—multithreading can be tricky
I've seen multiple 4-way SMP rumors in comments in the last few weeks. Was there something hinted at, or a "leak" implying this might happen? I did a brief search but didn't find anything.
I'm curious if anyone knows about that image of the AMD cpu - it says on it:
"DIFFUSED IN USA"
What exactly does that mean? Given the next line is "MADE IN CHINA", it would seem like "DIFFUSED" should be "DESIGNED" - or does that word have a new meaning?
NUMA isn't a feature, it's a design compromise. Ideally every line of memory takes the same amount of time to access. But in large complex designs, you can increase performance for some memory at the price of lower performance for other memory, aka Non Uniform Memory Access.
I believe these chips have Uniform Memory Access via a shared memory interface on the I/O die. Am I mistaken?
Edit, just confirmed:
>Thanks to this improved design, each chiplet can access the memory with equal latency. The multi-core beasts can support to 4TB of DDR4 memory per socket.
They exhibit NUMA because if chiplet0 wants a line of memory that is held by chiplet4, it has to go get it from chiplet4. So the degree of NUMA is improved from the previous generation, but it is still not UMA.
Generally caches aren't considered to be "memory" in this sense or otherwise every multi-core chip would be considered NUMA since they all have private caches. Instead you normally talk about an architecture being NUMA when cores have different access speeds to different parts of main memory, as when you need to get another socket to forward you information from a RAM bank. This is something that the OS generally has to be aware of in scheduling decisions, unlike caches which are automatically managed by hardware.
The chiplets have cache, which holds copies of memory. If a process has the line open in an exclusive state, e.g. locked, other chiplets cannot just get the line from memory, because it might be out of date. So they must go ask whoever holds the lock to flush & release.
Yields are the main barrier to single pieces of silicon that big. You have a certain chance of getting a defect per square mm of you chip and as they get bigger the chance of a bad defect gets higher and yields go down. Often they'll occur in a place where you can just disable a core or bank of cache and still sell the chip but not always. So yield rates tend to go down as chips get bigger. Also larger chips make less efficient use of the wafer.
Economically, there aren't so many people looking for 1000 cores that it makes sense to put in the NRE to assemble a giant package to put all of that in versus just selling a system that can have multiple sockets. Cooling limits also make spreading out work across multiple sockets a better choice.
As wmf said, what NVidia calls a "core" isn't something that can issue it's own instructions so it isn't really something you'd normally consider a core, though it does have a PC and can compare its PC against the PC of broadcast instructions to decide if it should execute or not so it's a bit more sophisticated than a simple SIMD vector lane. Maybe on par with an execution port?
What's more equivalent to a CPU core would be what NVidia calls an SM and AMD calls a compute unit. These decide which instructions to issue next and broadcast them to the various lanes. You'll have dozens of them in a typical GPU, about the same as the number of CPU cores in the same silicon area.
Is there a market need for 1000 cores running simultaniously that doesn't already need all the other supporting infra you get from a couple extra "full fat" servers each running 64 cores? Presumably if there is any need, it's currently being done by gpus
