Strided memory access

[Mysticial]

Just curious, what happens if you remove all the computation and test the raw access pattern?

This could be a good starting for point inserting hardware counters.

[Mark Rose]

Originally Posted by Mysticial

The mesh cache is inferior to ring cache in almost every performance aspect. Core-to-core latency is about double. Bandwidth is terrible (only twice the DRAM bandwidth).

It's bad enough that I tune y-cruncher to ignore Skylake X's L3 and assume the L2 is the last level cache.

Obviously, ring cache has scalability issues. So Intel had to move off it at some point.

--------

The reason why I asked about how the multi-threading was done is to see if you're hitting the case of poor broadcast performance behavior. I don't think it applies here, but I'll tell the story anyway since it's really interesting and infuriating.

Basically if you write to an address, then immediately have multiple cores read it simultaneously, the performance is as-if they were writing to it instead of just reading. This royally screws up low-latency code where you want to signal to a ton of spinning threads that data is ready for them to consume.

What happens is that when a core cache misses on a cache line that is in another core's cache, it always pulls it in for ownership (and evicting from all other caches) as opposed to just shared - even if the access is a load. The effect is that if you have say - 20 cores spinning on a variable waiting for it to flip before continuing, the cache line will bounce across the 20 cores many times each before the director realizes what's going on and finally decides to stop the madness and give it to everyone in shared state.

This reason why Intel does this is because they are optimizing for poorly written spin locks that do read + cmpxchg. Without this "optimization", both the read and the cmpxchg would result in coherency round trips - the read brings it in as shared, the cmpxchg upgrades it to exclusive and evicts from all other caches - thus double the latency. Good spin locks usually lead with the cmpxchg under the assumption of no contention. Only if it fails does it enter a read loop.

This has been the case since at least Haswell (never tested on anything earlier). And it got significantly worse upon switching to mesh cache in Skylake SP.

Interesting. What was your work-around for the broadcast situation?

[Mark Rose]

Originally Posted by Prime95

Poly multiplication takes 64 bytes from each input gwnum, zero-pads to a convenient FFT size, performs two length 100000 FFTs, pointwide multiply, and a length 100000 inverse FFT, then outputs 64 bytes to 100000 output gwnums.

Do you have a DDR5 system for testing on as well? I only mention this because DDR5 is capable of transferring 64 bytes of memory in a single burst, whereas DDR4 requires two. If you hit main memory this may have an impact on your algorithm's performance.

[Prime95]

Originally Posted by Mark Rose

Do you have a DDR5 system for testing on as well? I only mention this because DDR5 is capable of transferring 64 bytes of memory in a single burst, whereas DDR4 requires two. If you hit main memory this may have an impact on your algorithm's performance.

I do not have a DDR5 system.

I struggled with this for quite a while trying various padding strategies. I can't say I learned much about how memory layouts affect performance. I did find that streaming stores were beneficial once data no longer fits in the L3 cache. In the end, best results were obtained by allocating the array of gwnums linearly in memory, then just randomly scrambling the array of pointers.

[chalsall]

Originally Posted by Prime95

I do not have a DDR5 system.

Is there any chance that could to provided to you?

"Virtual" could work. Translation of atoms can be very expensive.

Not to say knowledge is cheap...