True enough, but I personally hit bandwidth limits on occasion for my most heavy processing jobs (data analysis, wouldn't be surprised if the same applied to people doing media editing or working with databases).
Threadripper or cheap EPYC are looking quite attractive to me because of the high bandwidth per core and price-point. I just wish Intel would also compute on this point.
That's 12-memory channels too (6-channels per socket). You'd have to buy an expensive dual-socket motherboard, but its relatively high-end / server-class for a reason.
Xeon Gold and Xeon Platinum are just WTF with the pricing though. I guess those are for people who stopped caring about price/performance.
AMD EPYC still seems better on a price/performance front than Dual Xeon Silvers, if only because you can get a single-socket EPYC with 8-channel RAM. But Xeon Silvers aren't really that far away.
Yes, but you have to consider the NUMA-nodes and how good threading is on the two systems.
10-cores x2 == 20-cores on 2x NUMA nodes.
2x EPYC 7281 basically gives you 8x NUMA nodes. Your threads are really spread out, so its bad for major workloads like Databases (which may communicate heavily, and also benefit from the "combined" L3 caches on the Intel Xeon Silver setup)
In many ways, I'd argue that the "real" competitor to the Dual-Xeon Silver 4114 setup is the single-socket EPYC 7401P for $1200ish.
The EPYC 7401P gives you 4x NUMA nodes with 24-cores / 48-threads total, fits into a single-socket motherboard (way cheaper). This minimizes the NUMA crosstalk issue, still gets you a respectable 8-channel memory system and a large core-count.
The EPYC 7401P is the price/performance champ. Still, AVX512 or Database purposes may keep dual-Xeon Silvers in the running.
> Your threads are really spread out, so its bad for major workloads like Databases (which may communicate heavily, and also benefit from the "combined" L3 caches on the Intel Xeon Silver setup)
As soon as you add the second node for a workload with poor locality like that, half your accesses are on the wrong node. No matter how many more nodes you add, the worst it can cost is that much again.
The unified L3 is also probably immaterial when you have a large database like that which exceeds the L3 by hundreds of gigabytes and it's ~100% cache misses either way.
On the other hand, you have 60% more cores to make up for it.
I'm not saying there are no circumstances or workloads where the Intel system makes sense, but it's kind of telling that it's a matter of finding them as exceptions to the rule.
For the general purpose things like running a bunch of unrelated VMs that aren't affected by number of nodes much if at all (or benefit from them because one misbehaving guest or process thrashing all the caches and flooding memory bandwidth only impacts a single CCX/node), it seems like an obvious choice.
It's also going to be interesting to see how databases optimize for multiple NUMA nodes now that they're common. There should be ways to determine which parts of the database are on which node and then prefer to dispatch queries to cores on the same node, or keep copies of the highest hit rate data on multiple nodes etc.
Threadripper or cheap EPYC are looking quite attractive to me because of the high bandwidth per core and price-point. I just wish Intel would also compute on this point.