AMD Talks Up Vega Frontier Edition, Epyc, Zen 2, ThreadRipper

[coder]

Because Intel would never come up with anything like that, clearly you must be too young to remember Itanium.

Explicitly parallel instruction computing (EPIC) is a term coined in 1997 by the HP–Intel alliance^[1] to describe a computing paradigm that researchers had been investigating since the early 1980s,

No, there's really no equivalence between Intel's EPIC and AMD's Epyc. The former is somewhat legit, in that it accurately describes Itanium's instruction set (which was meaningfully different than VLIW) and isn't misspelled. AMD's Epyc has no legit reason - it's just tacky.

[coder]

Right now the standard-Ryzen 8-core stand pretty good in non-gaming tasks and in gaming tasks, if you can get the IF-bottleneck down by using overclocked RAM at frequencies of about 3200 or higher.

Now those processors are of course linked again via IF together. Does that mean, I solve that NUMA-bottleneck of increased latency the same way? Throwing in 3200 memory kits and have fun enjoying 16C/32T with no downsides - or is there more to it?

You're not reducing Infinity Fabric bottlenecks by using faster RAM - you're reducing memory bottlenecks. I'm sure you'll be able to find cases where faster RAM both helps and makes little/no difference for scaling problems in Threadripper. It'll be very case-dependent.

The main point of my earlier post was simply to alert people to the fact that Threadripper and Epyc will exhibit (sometimes significantly) different scaling behavior than comparable sized Xeon CPUs. Since Sandybridge, Intel CPUs have featured one or more ring buses on which the cores, memory controllers, and bus interfaces sit. The ring buses are fast and all cores have a pretty similar distance to the memory controllers.

In synthetic benchmarks, at least, I wonder if we'll find bottlenecks resulting from cache coherency overhead, even when there's good data locality (i.e. the threads are accessing only data located in the memory banks attached to their respective dies).

Also, dual-Epyc systems will be extremely bottleneck-prone. You really want to treat them as 8x 8-core nodes that just happen to share an address space and kernel. Plan on either running VMs (or docker containers) or running NUMA-aware workloads. With so many cores, it's unwise to simply rely on the OS' scheduler to be reasonable and deliver good scaling in anytihng other than trivial cases (e.g. make).