4 ms·

Modern x86 (Golden Cove, Zen 3/4) is currently 6 wide. [https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021/11/goldencove.drawio3.png?ssl=1 https://i0.

Modern x86 (Golden Cove, Zen 3/4) is currently 6 wide. [https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021/11/goldencove.drawio3.png?ssl=1 https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2021...] A17/M3 is 9 wide [https://files.catbox.moe/vkbop7.png https://files.catbox.moe/vkbop7.png] From what I've heard, Veyron V2 has only 4 wide rename.

snvzz 3y ago
Zen4 is 4-wide[0]. I understand Zen2 (and thus 3) are also 4-wide. I do not know about Intel's designs. Has Apple officially published these details about M3? 0. https://en.wikichip.org/wiki/amd/microarchitectures/zen_4 https://en.wikichip.org/wiki/amd/microarchitectures/zen_4
- RaisingSpear 3y ago
  Zen4 has an 8 wide frontend (from uOp cache) but 6 wide rename, making the overall design 6 wide. Decode is 4 wide, but that only matters for code not sourced from the uOp cache (which is quite large). Apple don't publish much details of the core - most of what we know is intuited from benchmarking.
  - snvzz 3y ago
    >Decode is 4 wide, but that only matters for code not sourced from the uOp cache (which is quite large). Yes, but decode is what we're talking about. uOp cache is clever, but as any cache it is costly (power, area) and necessary only because x86 decode is very hard.
    - RaisingSpear 3y ago
      It's counter-intuitive to think that way. Modern x86 is designed to primarily operate out of the uOp cache. You can argue about the cost of the uOp cache being expensive, but it's disingenuous to ignore it.
      - yaantc 3y ago
        Not really, GP was talking specifically (and exclusively) about the ease of decoding the native ISA. Yes, modern x86 are wide from the uop cache, but this cache is made of simple, easy to process uop and not native instructions. The native part is still "only" 4 wide. The whole existence of the uop cache is to avoid repetitive native instructions decoding and replace it by dealing with simple uop. That's because this native x86 decoding is expensive and hard to widen, which is exactly GP's point. You're saying the uop cache makes this a non issue in practice: maybe (cost/efficiency of this cache vs a simpler design? I don't know ;), but that was not the point GP was discussing. The point was only that the C extension is easy to decode, with as practical proof the width of existing implementations supporting it.

snvzz 3y ago

Zen4 is 4-wide[0]. I understand Zen2 (and thus 3) are also 4-wide. I do not know about Intel's designs. Has Apple officially published these details about M3? 0. https://en.wikichip.org/wiki/amd/microarchitectures/zen_4 https://en.wikichip.org/wiki/amd/microarchitectures/zen_4

RaisingSpear 3y ago
Zen4 has an 8 wide frontend (from uOp cache) but 6 wide rename, making the overall design 6 wide. Decode is 4 wide, but that only matters for code not sourced from the uOp cache (which is quite large). Apple don't publish much details of the core - most of what we know is intuited from benchmarking.
- snvzz 3y ago
  >Decode is 4 wide, but that only matters for code not sourced from the uOp cache (which is quite large). Yes, but decode is what we're talking about. uOp cache is clever, but as any cache it is costly (power, area) and necessary only because x86 decode is very hard.
  - RaisingSpear 3y ago
    It's counter-intuitive to think that way. Modern x86 is designed to primarily operate out of the uOp cache. You can argue about the cost of the uOp cache being expensive, but it's disingenuous to ignore it.
    - yaantc 3y ago
      Not really, GP was talking specifically (and exclusively) about the ease of decoding the native ISA. Yes, modern x86 are wide from the uop cache, but this cache is made of simple, easy to process uop and not native instructions. The native part is still "only" 4 wide. The whole existence of the uop cache is to avoid repetitive native instructions decoding and replace it by dealing with simple uop. That's because this native x86 decoding is expensive and hard to widen, which is exactly GP's point. You're saying the uop cache makes this a non issue in practice: maybe (cost/efficiency of this cache vs a simpler design? I don't know ;), but that was not the point GP was discussing. The point was only that the C extension is easy to decode, with as practical proof the width of existing implementations supporting it.