bakaneko (nyan.delete@this.hyan.wan) on May 20, 2018 7:25 am wrote:

> Anyway, here the full thing if you want to look through it:
>
> https://pastebin.com/CM6puF0Q

Thanks for these results. Can you tell me what Zen+ chip you have?

After a brief scan comparing to results to Skylake, here are my notes (these are largely similar to original Zen):

• Zen seems to only be able to a 64-bit multiply every 2 clocks, compared to Skylake (and many earlier Intel generations) which do them at 1 per clock. I don't remember that from the earlier Ryzen results and haven't seen it mentioned before, so it might be a test artifact somehow.



• Zen has quite a bit more of a glass jaw when it comes to unaligned loads and especially stores. On recent Intel, there is no penalty for any load or store, no matter the alignment as long as the access doesn't cross a cache line (64-byte) boundary. If it does, it simply costs about the same as 2 accesses.
  
  Zen on the other hand also has a penalty for any load that crosses a 32-byte boundary, and any load that crosses a 16, 32, 48 or 64-byte boundary. The penalty itself is also must larger for stores: only one such store per 5 cycles (except in the special case where an 8-byte store exactly straddles a boundary with 4 bytes on each side: in this case the store takes only 2 cycles). I don't know how the penalized and non-penalized stores overlap if they occur in sequence, but it means that average cost of a 64-bit store over all alignments is 1.1 cycles for Intel and 2.6 cycles for AMD. The average penalty is smaller for smaller stores and larger for larger (SIMD) stores.



• Store forwarding latency seems to be 7 cycles generally on Zen+, with some cases around 6 cycles if the load happens to occur at just the right time (5 or 6 cycles after) the load. The situation on Skylake is more complex, but it's generally faster at around 4.5 cycles or as low as 3 cycles if the timing is right (if the load issues 3 cycles after the store).



• Zen seems to handle software prefetching differently than Intel. On recent Intel, software prefetches are treated as a "must complete" and behave in some ways like loads without a destination register: i.e., they cannot retire until the data has been fetched. So a dense stream of prefetches behaves much like a dense stream of loads from the same cache level. On Zen, prefetches seem to execute 2 per cycle, even when striding over large regions where 2 cache lines per cycle throughput cannot be sustained. My theory would be that if all the fill buffers are full, Zen drops prefetches rather than waiting for a free buffer as Intel does. Both strategies are reasonable and allowed by the ISA documentation. The Intel approach is probably a bit better for carefully tuned kernels where the prefetch instructions are nearly all ultimately useful and issued at the right time, whereas the (alleged) AMD approach favors "real" loads over prefetches and is probably useful in cases where a developer has put in some best-effort prefetches but where the data isn't always subsequently used or where there may be less tuning.



• Zen has 12-cycle L2 latency and throughput of 1 cache line per 2 cycles. Intel is similar, but has a bit better throughput at about 1 line per 1.66 cycles. Given that the AMD's L2 is twice as big, you'd probably have to give AMD an overall edge in L2 performance (of course, Skylake-X now has a 1MB L2).



• Zen L3 performance has a high apparent throughput of 2 cycles per cache line, similar to L2. This is for a stride over a 2 MB region. This is much better than Intel's line per ~4.8 cycles, but I'm not sure we can can conclude much here since the core is downclocked to 1.5 GHz, and L3 is an offcore thing that probably runs on its own clock. So the performance may only be great because we are measuring in 1.5 GHz cycles something that largely hasn't been downclocked. A similar comment applies to latency.



• Ryzen has might higher throughput for popcnt, tzcnt, lzcnt and some related instrutions that Skylake and has no false-dependency issue with these instructions.



• The latency of cache-line crossing misaligned loads (as opposed to throughput, discussed above) is considerably better on Zen than Skylake, with only 1 cycle penalty compared to 6 cycles for Skylake.

On thing that strikes me based on the above is yet another kind of built-in advantage the incumbent like Intel has. People (including compiler writers) make optimization decisions based on the existing deployed hardware (and sometimes just the hardware they are using), which tends to bias the current crop of software (and benchmarks) to the performance profile of the dominant uarch: if another uarch picks a different set of trade-offs, that might actually be better overall, it won't pan out that way on today's software which is optimized for the other behavior.

For example, for a long time unaligned memory accesses really sucked and people avoided them. The last few Intel uarchs, however, have reduced the cost for most types of unaligned accesses almost to zero, so you have been a shift in hand-optimized code and (more slowly) compiler heuristics towards more unaligned accesses and fewer big-and-slow prolog and epilog code sections to align mode, etc. Since AMD has chosen a different tradeoff there, they will probably be hurt somewhat by that change. On other hand, people aren't going to generally do something that is slow on Intel even if it's fast on AMD, people aren't going to target a 512 KiB L2 versus 256 KiB except in very specialized cases, etc.

Now Ryzen is actually quite close to the performance profile of Skylake, both in absolute terms but more importantly in the types of things that are fast and slow, so this probably won't hurt them too much: but one has to wonder if they feel somewhat restricted in their design in the sense that they are compelled to be fast on code that is written to be fast on Intel.

To some extent this even constraints Intel: it would be hard for them to make a radical change that makes some things much fast and others much slower, that they believe to be better overall (once software has adjusted), because it will test poorly on release because existing software and benchmarks are written for the chips of yesterday. So they are compelled to at least hold the line kind of across the board performance-wise (and indeed, the last many generations of chips have largely seen removal of glass-jaw type slowdowns, rather than radical speedups in any area). It's not as much of a constraint though, since they can still release something that holds the line but is faster is some mostly-unused-but-key area, and then expect people to take advantage of it over time. AMD, not so much (at current levels of market share, anyways).