What could they do next gen to alleviate the memory issues with 2990wx?
Aside from different topologies, would adding a large L4 help much?
Aside from different topologies, would adding a large L4 help much?
I have a possible explanation:Ian Cutress said:you will notice that our 2990WX sample never goes near the 250W rated TDP of the processor, actually barely hitting 180W at times. We are unsure why this is.
Enermax's rating of their AIOs is utter nonsense. If you try to push 500 W thermal load through a slim 360, slim 280, let alone slim 240 mm radiator, it's not only going to be very noisy, the loop will also become very hot. So hot, that AMD's boost will put a lid on the clocks, voltage, and power.Ian Cutress said:Most of the testing data is with the Liqtech 240 liquid cooler, rated at 500W.
What could they do next gen to alleviate the memory issues with 2990wx?
Aside from different topologies, would adding a large L4 help much?
Ok, assuming AT did proper testing of the connections and not using whole uncore...
Now IF is worse than intel mesh...16 core consume slighly more power than intel 18 core at max...but the real story is MINIMUM connection power consumption...it is considerably more on AMD IF than on intel mesh..and nearly an order of magnitude worse when comparing intel ring bus to pinnacle ridge IF...(baseline).
Power consumption looks reasonably equivalent between mesh and IF when using AMD 2 dice Vs 18 monolithic intel die...but connecting 4 dice is a massive amount of power for either Epyc or 2990wx...using that much percentage of power is not ideal.
I'm saying using IF to connect multiple small 4 core CCX for desktop is a bad situation long term, even worse when using multiple IF links to connect 4 of those dice together for threadripper.
They would be better off moving to a new more efficient topology for a larger CCX, better connections between CCX, finally some kind of active interposer with advanced topology for connecting dice.
Most people seem to think ..large ring bus CCX + active interposer+butter donut is a better long term solution.
What could they do next gen to alleviate the memory issues with 2990wx?
Aside from different topologies, would adding a large L4 help much?
16 gig of HBM 2 as L4, squatting between all those dies would likely help a LOT. But the cost won't cut it yet. This year anyway it's a Unicorn.It will just increase latency, because now they need to look up l4 before ram.
OMG, people are complaining about gaming performance.
Gaming wise, the chip is still a beast. I plan on jumping on the 2920x Should be near the same level of performance.
Hardware unboxed explained it in a way I finally understood -
https://youtu.be/QI9sMfWmCsk?t=3m49s
And how that impact memory bandwidth
https://youtu.be/QI9sMfWmCsk?t=17m3s
Tech Report's review shows that while frame rates on the 2990WX might not be completely catastrophic (though they're certainly on the low side), there are some pretty nasty frame latency spikes.Don't see why. I did read a lot of posts about how TR2 will suck at gaming,but.....first post on this thread from mark
Gaming wise, the chip is still a beast. I plan on jumping on the 2920x Should be near the same level of performance.
Only on large data sets though surely? If you had a large chunk of L4 with good bandwidth, even 256mb...that would cut alot of traffic to main memory and improve performance of some workloads by decreasing latency.It will just increase latency, because now they need to look up l4 before ram.
Even if it was on die, that would presumably only add latency on certain workloads, most of the time it would lower latency no?.Where an L4 cache would help is on each die. It would need to be at least 8x (preferrably 16x) as large as the combined L3 cache size on each die (to account for the 4 die configuration) and would definitely add another few cycles of latency for memory access. So, that's 128MB per die minimum and preferrably 256MB. That's a LOT of die space. However, for a 4 die TR2, that's an L4 cache of 512MB to 1GB in size. To make that work effectively, you'd need to increase inter-die bandwidth significantly. With the advent of PCI-E 4.0 and 5.0 though, that base clocking approach can help solve this (IF borrows a lot from it it seems).
so, in the long run, I think that we'll eventually see an L4 cache on the Zen die in future iterations. I also see that, eventually, there will be a split in the lines with Epyc and TR-WX series getting die that are custom made for them and may be able to filter down to the HEDT market in another performance tier.
That actually would explain a fair bit. nVidia's driver supposedly makes pretty heavy use of multi-threading, so if it's making bad choices which cores/dies to allocate threads to, performance is going to suffer.https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https://www.golem.de/news/32-kern-cpu-threadripper-2990wx-laeuft-mit-radeons-besser-1808-136016.html
Interesting, looks like Nvidia's driver doesn't work properly.
Interesting, looks like Nvidia's driver doesn't work properly.
Only on large data sets though surely? If you had a large chunk of L4 with good bandwidth, even 256mb...that would cut alot of traffic to main memory and improve performance of some workloads by decreasing latency.
16 gig of HBM 2 as L4, squatting between all those dies would likely help a LOT. But the cost won't cut it yet. This year anyway it's a Unicorn.
I am not sure, but it occurs to me that this case should be handled by any NUMA implementation from day one, because it is just a variation of the case that the memory of a node is fully allocated, while another node still has free memory.Anyone knows why Linux already supports this thing of having NUMA nodes whiout local memory?
TR already have plenty cache, and it's search in each l3 cache before going to ram so it's not worth it if they added another level of cache, it will just increasing the cost and latency but will not have a meaningful increase in performance. What AMD need to do is increasing the IF frequency but with the current power consumption I guess AMD really need that 7nm.
TR has plenty of cache for the total package, but, we're looking at very specific use cases here. A large L4 cache for each die would enable each die to keep a local copy of the contents of each remote L3 cache local to each die. This would alleviate the strain on the IF links between the various Die and reduce the power demand on it as a result. It would also alleviate the issues that having distant RAM on TR-WX packages can cause. Yes, there would be invalidation and copy traffic, but, in most use cases, that would be a "less than frequent" case for a properly NUMA aware scheduler OS. Now, will it be expensive? You betcha! Will it be worth the cost at 12nm? Absolutely not. At 7nm? Maybe on 7nm+ for a hypothetical die that's targeted at EPYC/TR/HEDT AM4. I think that as AMD gets better market penetration and volume on their products, they will also have enough revenue to have three different actively developed die: Power and Size optimized Ryzen Mobile (current Raven Ridge), Clock optimized Ryzen Desktop (current Zepplin) for AM4/TR-X, and balanced Ryzen HCC for EPYC/TR-WX/HEDT AM4. Mobile and Desktop can stay at GloFo and Server can live at TSMC, each on a process node that fits their use case. With a separate HCC die, they can afford to make tweaks to it that address these shortcomings, such as adding extra CCXs and an L4 cache.
https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https://www.golem.de/news/32-kern-cpu-threadripper-2990wx-laeuft-mit-radeons-besser-1808-136016.html
Interesting, looks like Nvidia's driver doesn't work properly.
I don't think Linux is aware of the specific NUMA architecture at all.Anyone knows why Linux already supports this thing of having NUMA nodes whiout local memory? This has to be the reason of why it performs so bad on Windows compared to Linux.
Just guessing here, maybe they decided to improve performance for EPYCS whiout all 8 memory channels populated?
I am not sure, but it occurs to me that this case should be handled by any NUMA implementation from day one, because it is just a variation of the case that the memory of a node is fully allocated, while another node still has free memory.
Not true.But the design of L4 cache is always because constraints in bandwidth not latency, just like why broadwell and Xbox one use it, and when there are available faster memory option they abandoned it ( in this case ddr4 or gddr5). And the problem with TR isn't about bandwidth but latency, and when ddr5 come out it wil bring much higher bandwidth, and making adding l4 cache is kinda useless.