Read more.Quote:
Seems to confirm that some 7nm third-gen Ryzen processors could feature >8C/16T.
Printable View
Read more.Quote:
Seems to confirm that some 7nm third-gen Ryzen processors could feature >8C/16T.
Obviously that should say AM4.Quote:
Originally Posted by Article
Weird question, AIDA is a clinical diagnostics suite on a particular brand of pacemaker. Coincidence or some weird crossover?
Can't tell if you're not familiar with AIDA64 or if you're just calling a bluff on the "coinkydink" that AIDA64 is the first system analysis/benchmark tool supporting AMD's "Matisse". AIDA64 has been around for ages (at least 15 years if not more). There's also a version for Android, if I remember correctly.Quote:
Originally Posted by philehidiot
As for "Matisse" itself, I'm getting more hyped every time I read something about it. I *really* hope it isn't unjustified.
tbh the most interesting thing in this whole story - which is getting ignored - is the cache latencies. The lack of a latency spike at 8MB suggests that either the compute die is a single 8 core CCX (which others have speculated but I was skeptical of) or that they've completely fixed the inter-CCX communication delays on the compute chips.
Now, since the compute chiplets would have their own on-chip fabric connecting the CCXes, it's not inconceivable that they've been able to tune that fabric to remove the latency between CCXes completely, since it's no longer part of a larger domain including the memory controller.
OTOH, the fact that latency actually reduces past the 32MB point (once you're going direct to main memory) can only indicate that the inter-chiplet latency is terrible. I rather wonder if that issue is the one that's holding AMD back from officially announcing > 8 core Ryzen 3 at this point...
Nah I was just wondering if it was some engineering thing. We get a lot of stuff in my area which is applied to humans which comes directly from engineering stuff. I assume it is brought in by the engineers who have moved into the medical tech companies and thought "I wonder if we could apply this".Quote:
Originally Posted by azrael-
If we measure latency in block sizes then wouldn't that hide any on package latencies? E.g. If we measure how long it takes to read/write to a 4MB, 8MB, or more, block of memory we're measuring how long it take for the entire block to be read/written, a bit like how reading 50MB of data from the OD versus the ID is faster but reading 512MB from the entire disc is averages out the fast and slow parts.Quote:
Originally Posted by scaryjim
Nope - look back at any of my MANY posts about the Ryzen 1 and 2 stepped latency results. There's 16MB of L3 cache on there, but you still get a huge spike in cache latency at and beyond an 8MB step - i.e. once a core has to go outside its own slice of L3 cache and into the other CCX which is on the same die.Quote:
Originally Posted by Corky34
The removal of the latency spike at 8MB means something's different - either there's still 2 CCXes on a chiplet but there's no latency penalty when going to the other CCX, or there's only 1 CCX, with 8 cores and 16MB of L3 cache.
Just a quick addendum to the whole thing, on the really bad latency between 16MB and 32MB stride:
https://img.purch.com/02-jpg/o/aHR0c...FsLzAyLkpQRw==
From the Tom's Hardware article mentioned in this hexus article.
It's the problem I was worried about in this post: https://forums.hexus.net/cpus/371038...ml#post4057940
Based on the way large cache access latencies are worse than main memory latencies for this chip, I think it confirms that any cache access outside local L3 cache is going through the IO chip, not on a direct chiplet-chiplet link. Basically it looks like the worst-case scenario I was worried about with this topology has been confirmed...
See if i can put it another way, if you're measuring how long it takes to read/write a block of memory you're not measuring latency you're measuring access time, to measure latency you need to send a ping from one place to another otherwise you're just measuring how long it takes read/write X amount of data.Quote:
Originally Posted by scaryjim
It's the difference between saying i can download a 40MB file in 1min and saying I've got 1500ms latency to the server I'm downloading from.
You seem to be splitting hairs on a completely irrelevant point. The entire industry uses the term latency for what's being measured by this test. What you call it isn't the point. How it behaves is the point, and Zen 2 behaves differently to Zen 1, when using the same test.Quote:
Originally Posted by Corky34
It's not irrelevant because until now making the distinction was pointless, the time taken for different cores to access the same memory was a constant as were the latencies, just like they still are within a single Zeppelin die, it's only when splitting your 'local' memory into two physically separate chunks that that no longer applies.
Making the distinction now is still pointless. Cache and memory latency is a well defined property with a well-specified measurement protocol that has a known and predictable impact on CPU performance. It's a measure of how long it takes from requesting some data to having it available to process. It's usually measured in nanoseconds these days, and it's significantly affected by cache hierarchy and design decisions which is why it's a big thing for Ryzen.Quote:
Originally Posted by Corky34
What do you think latency is?
EDIT:
I've just gone back and looked at another thread and I think I get it - you're talking about ping latencies between cores, which, yes, are a type of latency. But they're not the one I'm talking about, and they're not relevant to my point, which is about cache and memory latencies.
I know what you're talking about but you're (not personally) using UMA benchmarking programs to measure what, as you've rightly pointed out, is a NUMA system, or at least a ccNUMA system, when using a UMA benchmarking program to measure latency/speed/access time (different programs seem to name it differently) you're measuring one of the same thing because latency and access times are equal.Quote:
Originally Posted by scaryjim
However with a ccNUMA package latency and access times can vary depending on the bandwidth of the link, although this article talks about HDD it's the closest thing i could find that, i hope, does a better job of explaining what I'm trying to say.
EDIT: BTW I'm not disagreeing that there are differences in access times or latencies, I'm trying to say that outside of programs specifically designed to measure the differences that exist between these things that i doesn't, or shouldn't, matter as normal software (excluding the OS and aforementioned software) is totally unaware of the differences, Oh and also that using the aforementioned software to measure the latencies on a NUMA system can be misleading.
tbf I still don't think that matters (although considering NUMA here is perhaps a little questionable, since I'm pretty sure Ryzen processors don't present themselves to the OS as NUMA anyway...).Quote:
Originally Posted by Corky34
The whole point of the latency ladder test is to determine the step/block sizes at which latency changes. So it's still valid to talk about latency, and it's still valid to interpret the results as it highlights the changes in cache latency as you move through different sizes of data workload. In a sense, it's more relevant to NUMA systems as you can test different NUMA nodes and compare them, highlighting any anomalies.
In the case of this (apparent) 2-die Matisse processor, it highlights two things - the first it that there's no step-change in latency until you hit ~ 16MB step, and the second is that the 32MB step has worse latency than the larger steps.
The first point is key because Zen/Zen+ CPUs did have a step change in latency at 8MB, which represented the additional latency of retrieving cached data from a different CCX. That's been eliminated in Zen 2.
The second point is key because it means that - so far - AMD haven't managed to hide the additional latency of retrieving data from the cache of the other compute chiplet.
As to the difference between response time and latency, I kind of see what you mean, but with the type of data retrieval these tests do you're not going to hit anywhere near the point where the system bandwidth is the limiting factor in the test. The article you referenced is going back to non-volatile storage, which is several orders of magnitude slower than RAM, which itself is orders of magnitude slower than cache. You're working at the level where - as the article identifies - latency and response times are actually the same.
Sort of yes to everything up to there, however i suspect that it's not been eliminated, or at least it's unknown if it has, i suspect the the way the measurement is being taken is hiding the latency, that's a good thing in a way but it may not tell us much about how the caches are configured.Quote:
Originally Posted by scaryjim
I get where your coming from but I'm not sure i agree, sorry. :) I'm not saying either of us are wrong or right, it's just I'm a little hesitant to say exactly what it does show us due to the possible changes in cache sizes, I/O die, perhaps an increase in bandwidth of the data link, etc, etc.Quote:
Originally Posted by scaryjim