On the matter of using EPYC interposers to get 8 memory channels - why? Hereâs my thoughs on why not:
EPYC interposers are more complex and therefore must be more expensive to produce. AMD already have a working, simpler interposer design that they used on 1st gen Threadripper.
AMD would be going back on their promise of (backward) compatibility.
It benefits AMD to have EPYC have multiple advantages compared to Threadripper, so they can sell those for higher price.
Having use for dies with failed memory controllers (and PCIe controllers) allows AMD to increase their effective yields.
Controllers for 4 extra memory channels will use power, that on workstation type workloads might be better spent on the processor cores.
Phone auto correct being more cantankerous than usual⌠dry fingers?
TR1 was 2 hot and 2 dark dies. âworking⌠designâ is only true for 16 core configs. 32 is new no matter what (though it is conceivable they tested it previously - I/we donât have that info).
âmore complexâ? is a relative term here yes the TR1/2 donât use the off-chip infinity fabric channels, but the interposer is a PCB, so that sort of complexity is not really a barrier. The TR is a sub-set of Epyc functionality, so you have dark wires? No biggie. Upside to them is one and only one interposer to build/fab/test.
They can market/sell on binning/qual/support and other security features. They donât have ECC like Intel, but this wouldnât make or break them (but, along with binning for bad memory channels is the most compelling argument for them fusing off 2 of the memory channels).
Where I land is that it is entirely possible that either scenario is true - they may have fused off the other channels, or they may be relying on MBâs not wiring them up. Given binning and BIOS control, it may not matter in either case because as a practical matter, you wonât be able to get it to work.
TR is aimed at workstations! Who in their right mind builds a workstation (max stability and power efficency are key factors) and then overclocks it?
TR has 4 channel RAM access, two dies will have to ask their neighbours for RAM access or (even worse latency wise) have to shout into a general pool for RAM fetches. TR and Epyc will stay seperate for the sake of target audience (high-performance single socket workstation VS high-performance multi-socket servers).
Probably not, because else the dies would be good enough to become an Epyc CPU. This way, AMD can even use silicon with dead RAM controllers.
TR is aimed at HEDT which is broader than just workstations, but even then⌠efficiency is a fairly distant nth factor in my personal world (within reason - I still need it to run from a wall socket and not cook my office).
Why the anger at OC? I very much understand efficient and easily cooled as a benchmark for a large segment. I divide my personal world into 2 categories:
âstable, easy to cool, noisy as it wants to be, but water is less than idealâ. Those machines go into the rack. I donât want to fiddle with or maintain them. I want to batch jobs to them and run them for weeks on end without concern for random issues. Those are mostly xeons/ecc right now.
"fast as it can possibly go on an (un)reasonable budget with COTS hardware. I use this sort of thing for debugging and exploration of software. Iâm not going to die if it freezes or gets a random error, but to be honest, OC is just not all that difficult to get 24/7 stable these days. I ran my 7980XE at 4.5GHz for the Bionc Pentathalon - 2 solid weeks at roughly 100% non-AVX load. Iâve run multi-week high load jobs for work projects as well. I canât recall a single crash that didnât occur while I was tweaking the OC intentionally.
Classic âlatency vs throughputâ⌠If I want through put - slow and wide is fine. If I want low latency, fast and as wide as I can go at that faster speed.
The way I see it is that if you want AMD to reach or exceed parity with what Intel is offering in terms of the whole space, then you need to consider OC as well. As per prior posts, intel is releasing product assuming LCD (Lowest Common Denominator) heatsinks, LCD VRMs, LCD PCB/MBs, LCD memory etcâŚ
Their specs are wildly conservative relative to what 80-100% of their chips can do off the shelf with better cooling, more VRM capacity and tight tolerance PCBs/memory routing.
AMD is either going to need to reach this same point or they still have room for improvement.
Overclocking does not matter apart from publicity. It is a leftover from the time when chips came with 35MHz clocks and cases had turbo-buttons.
For benchmarks and competitions, there is overclocking. Real world outside of tech-communities, noone overclocks their daily driver. Simply because a few FPS do not really matter or because people are afraid of touching anything in their BIOS/UEFI.
HEDT became the techpresses favourite word after âgamingâ and âproâ got put into product names.
Edit: Looked up HEDT, it is an Intel marketing term (from arround the time of megatasking)
Iâm sorry, but both of these assertions are demonstrably false.
First, I run my DD OCâd. Iâm not alone. If you look into the world of âtrading platformsâ, you will see that there is a booming, very high margin market for even exotically cooled rackmount systems (but also work-stations) that first overclocked existing Xeon/HEDT parts and then began to get enough market clout to have Dell/Intel provide OEM SKUs with higher multipliers (OEM 2696v3 @ 3.8GHz vs RETAIL 2699v3 @ 3.6GHz both 18 core parts as an example)
Second, OC head-room in the present context (of the last 10+ years) has been a proxy for yield. AMD is still playing catch-up here. The 10nm debacle might change, or may have already changed that, weâll seeâŚ
Those models with more OC head-room are generally much more efficient at their marked speed (lower temp, lower voltage) than models that are running at the bleeding edge of their respective Si process.
This is a reflection of the exponential nature of power consumption, resistance, etcâŚ
You are painting OC with the broad-brush of marketing bluster, but the reality is that it both informs the market as to whoâs process is more robust as well as offers large niches the ability to achieve next generation performance from current gen parts if they are willing to pay for better cooling, VRMs and power consumption (the increased cost of which pales in comparison to the value of 20-50% more performance from any given generation of parts).
Itâs not as different from the way 1st gen threadripper works as some may think.
Even first generation TR has only 2 memory channels per die. The âquad channelâ thing is a bit of a misnomer, any individual die can only directly access memory via 2 channels. The other two channels of the âquad channelâ memory are via the infinity fabric and other dieâs memory bus. TRv2 simply adds another two dies that need to share memory bus of the other dies entirely, rather than having their own memory channels.
Yes, memory bandwidth will be a thing in highly memory bandwidth sensitive scenarios, but fortunately Zen has some big caches.
If youâre memory bandwidth limited - sure, youâd be better off looking at Epyc or intel (maybe? see below). But there are plenty of processing intensive workloads that are not so bandwidth constrained.
Remember, even on an 18 core intel i9 CPU, there is still only quad channel memory access for the entire die - you still have up to 18 cores fighting for 4 channels of memory. Sure, they donât need to go via infinity fabric, but they still have the mesh bus, and theyâre still over-subscribing those memory channels.
The topology may be different, but on say 16 core TR vs. 18 core intel, each core overall only has roughly 1/4 of a memory channel worth of bandwidth to main memory.
Intel also does higher core count processors than 18 on quad channel boards in the Xeon rangeâŚ
Waiting to see numbers on how much of a concern this really is, but the issue is less quad vs octal channel memory as it is path from a memory-less node to memory making latency very uneven relative to Intelâs mesh or even ring approach (which had hit a wall scaling to core count).
The Epyc NUMA configuration already requires OS/Application re-work to optimize for the cost of reaching any given nodeâs 2 channels. TR2 now presents a degenerate sub-set of that NUMA config where 4 of the CCXâs (the OS on their behalf) cannot optimize their memory map to avoid adjacent node hops over the fabric for memory access.
Again, we donât know how bad this is until we see the chip in the wild and even then, its impact will be wildly uneven depending on application, but⌠Itâs a problematic approach whoâs impact is likely felt long before you are âmemory bandwidth boundâ.
"Just buy Epyc"TM doesnât address the top-end clock issue. Epycâs are (for good reason) lower clocked parts.
True, but the question is not necessarily âhow much of a problem is itâ so much as âhow does this chip for $X compare to competitor chip for $Xâ.
Its definitely a compromise, but if it means you get 32 cores for the cost of say, 16-18 or less from intel (and they outperform inteâs 16-18 core), itâs a win. Even if in some/significant number of cases those cores are memory starved.
That and real-time ML (used in this exploit) is a Pandoraâs Box for exploits well beyond prior specter/meltdown.
This further cements my assertion that we need to start thinking very differently about computer security. The idea that we are even converging on an inherently secure hardware solution is a fantasy that is getting more distant by the day.
This means re-thinking network structure, hardware as a service, cloud, etc⌠and the much harder question of addressing the human factor (the people doing the exploiting). As it stands there is less than zero consequence to the overwhelming amount of malicious activity on the net (less than zero because some/much of it is state sponsored).
This level of exploit and the performance problem(s) of stopping it and things like it demand partitioning of secure and insecure hardware and stamping out the malicious people and organizations exploiting bugs.
Crypto keys are like door locks. They keep honest people honest, but if you think they make your network or files impenetrable, you are fooling yourself.
So in order of relative vrm quality for 32core/tr2 overclocking, how would you rank the popular x399 boards (e.g. taichi vs zenith extreme vs carbon ac)?
Yup. The whole root-CA thing is a house of cards and iâm sure that the US government has probably infiltrated a number of them and can issue certificates to impersonate whoever they like if you trust the root CAs.
Fair enough. Figured it was relevant as so far it looks like AMD is unaffected, and disabling HT will have a massive impact to IPC, which is one of the advantages intel has over AMD.
i.e., it is relevant to the performance comparison of the CPUs being discussed. if you turn off HT on intelâs 28 core, it is only 28 threads instead of 64 with AMDâŚ
Your good. Disabling HT will be enough of a performance hit that it will remain on by default plus the vulnerability wont really be effecting mainstream users
doesnât address the top-end clock issue. Epycâs are (for good reason) lower clocked parts.