Adrian (a.delete@this.acm.org) on July 30, 2022 9:27 am wrote:
[snip]
> AMD has stated clearly that there will be no ISA difference between the compact core and the big core,
> so it must also support AVX-512. This was obviously meant to contrast with their competition, who
> always had such differences, e.g. Denverton vs. Skylake Server (launched at the same time).

While such ISA compatibility has significant benefits, I suspect AVX-512 is expensive to implement in a small core because of the large architected state (32 64-byte registers plus mask registers). While a "low performance" core would not have to have as much register renaming and would presumably have fewer execution resources, the large state still feels burdensome. Some resources could be shared between cores in a Bulldozer-like design. Some resources might shared between threads (if multithreading is supported in a low performance core). GPU-style wider register access than execution and traditional banking could reduce the port count and thus area, but a 8 KiB single-ported register file would still seem to be kind of chunky. With sharing across cores, if AVX-512 is lightly used by both cores or heavily used by one, the active state could be smaller.

Narrower execution and sharing across threads would tend to reduce the need for rename registers by hiding some latency.

(I suppose, if full AVX-512 use is expected to be uncommon for small cores, it might be practical to steal storage from L1 cache to provide enough state for correct operation when more than eight or so registers are used. Even AVX2's 16 32-byte registers seems large for a core oriented for size. In terms of energy/power, power gating may minimize the effect of more architected state when the state is unused.)

Another consideration is whether smaller cores are designed for throughput — where wider execution would be desirable — or power/area. SIMD-friendly workloads would benefit less from out-of-order execution and other area/power-expensive features, so one could imagine a smaller core providing relatively high performance for such workloads but not preforming as well as a great-big-OoO design for "general purpose" workloads.

> For now, it is certain that the compact core will have less cache, but, as you say, it might also have
> vector units of reduced width. According to leaked benchmarks, Genoa appears to have an identical AVX-512
> throughput per core with Sapphire Rapids, which implies two 512-bit FMA units, so if not with a reduced
> width, the compact core might be simplified at least by having only one FMA unit instead of two.

While I do not have a suggestion for an architecture better than AVX-512 in terms of supporting blocking (it seems the anti-SIMD/scalable vector architectures orient toward streaming with little value reuse), efficiently exploiting data level parallelism, and supporting a diverse set of reasonable microarchitectures, I think AVX-512's flat state explosion makes small implementations problematic. I suspect even an architecture aware of data reuse would need to consider lifetime, access pattern, and scale, so a software-exposed storage hierarchy would probably not be sufficient. I also suspect that routing factors should be considered; while SIMD simplifies data and instruction routing (a single instruction is "broadcast to all functional units" and data forwarding/dependencies are common for the entire width), there may be opportunities for simplifying data routing. E.g., local conversion of array-of-structures to structure-of-arrays format [which is reminiscent of matrix transposition and probably part of a broader class of data rearrangements] could reduce work — compared to multiple strided vector loads implemented straightforwardly — and might be cacheable.

I suspect the concepts from "cache oblivious" software have some application to scalable hardware interfaces, but I also suspect that a latency (and bandwidth) hierarchy is not sufficient. While microarchitecture can compensate for architectural limitations, better interfaces still seem to have value.