2 ms·
That's not at all what I'm seeing. Can you be specific as to what chips you are looking at and what benchmark you are using to draw this conclusion? I'll go f
by sliken 5y ago
That's not at all what I'm seeing. Can you be specific as to what chips you are looking at and what benchmark you are using to draw this conclusion?
I'll go first.
Personally when talking about memory latency, I want to measure time to main memory, without TLB thrashing. Not that TLB latency isn't interesting, but it should be separately quantified.
I've written a few microbenchmarks in this area, but I get very similar numbers to the Anandtech R per RV prange. Which puts the latency to main memory at around 35ns looking like it might flatten out at 40ns. Yes, full TLB thrashing is up at 110ns or so, but that's not a usual use case. If it is, at least under linux, you can switch to 1GB pages if that's important to you.
R per RV prange numbers on the Ryzen 9 5950x is 65ns or so.
So sure the TLB worst case is higher latency on the M1, but then you have to figure out how big the TLB is, and how often that's an issue if you want to know the real world performance impact.
The i9-12900K with DDR5 gets 30ns on the R per RV prange, and 92ns on full random (tlb thrashing).
Even assuming the worst case TLB behavior the m1 max is 111ns and the 5950x is 79ns or 1.4x higher. On the Intel side is 111ns vs 92n, 1.2x higher.
Finding it hard to find any numbers that make the M1X look like 3x higher memory latency.
- formerly_proven 5y agoI feel like R per R isn't quite the perfect match for the pointer-chasy workloads I have in mind where you end up going through more-or-less random selections of relatively small (<< page size) objects, so R per R amortizes the randomization a little much. I still think having the overall totally random access for a system is a good number precisely because it contains all the penalties and latencies that can add up. Embarrassing as it may be, I also compared the wrong numbers across parts here (and in the past too, I think) - thanks for calling that out. I was kinda irritated how exactly they would be able to get the performance they were getting across all workloads with such poor latency but failed to double check.
- sliken 5y agoAh, sensible. Generally with the TLB numbers and the memory latency you can get a good idea of the performance by interoplating between the two number for any number of TLB misses (from 0% to 100%). The M1 Max also has a crazy number of memory channels, even the older M1 has 4 channels, pro has 8 channels, and max has 16. So you can have many more cache misses in flight, this is part of why the m1 max is 20% faster than the 5950x with twice as many cores.
- formerly_proven 5y agoHonestly it's kinda crazy what's possible these days. Couple years ago you'd easily burn 30+ watts on just the memory chips to get this kind of bandwidth.
- sliken 5y agoIndeed, 64GB ram, 400GB/sec, decent GPU, ML acceleration, 10 cores, etc all in a small package that gives good battery life to a relatively thin laptop. Here's hoping they put the same in the mac mini. Anyone interested in a linux port join the Marcan patreon, I'm kicking in a few $ a month.
- inkyoto 5y agoI have not seen TLB size reports for M1/M1 Pro/Max, but Anandtech has reported following figures for the A14: «The L1 TLB has been doubled from 128 pages to 256 pages, and the L2 TLB goes up from 2048 pages to 3072 pages. On today’s iPhones this is an absolutely overkill change as the page size is 16KB, which means that the L2 TLB covers 48MB which is well beyond the cache capacity of even the A14» [0]. For the default page size on A14 of 16kb, that gives the 4Mb L1 cache coverage (16kb * 256), and 48Mb (16kb * 3072) L2 cache coverage. Off the top of my head only POWER 9/10 (and maybe POWER11) come close with such large TLB's. aarch64 page sizes come as fixed presets, e.g.: - 4kb, 2Mb, and 1Gb - 16kb, 32Mb - 64kb, 512Mb The OS can choose either of the three, and OS X defaults to the 16kb / 32Mb preset, although I have not seen whether it can simultaneously handle both, 16kb and 32Mb, page sizes. A garbage collected runtime that has been optimised to make use of large TLB's or large page sizes can exploit the full advantage of the increased TLB depth. Azul JVM comes to mind with their ZGC garbage collector having been heavily optimised for terrabyte scale Java memory workloads. I am now very curious to see the M1 Max vivisection results that would reveal whether the TLB size in it is even larger (or not). [0] https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...