Travis Downs (travis.downs.delete@this.gmail.com) on July 13, 2020 7:03 am wrote:
> That's sort of the the point. You can measure pretty effectively the size of the vector
> units and register files (that's how you got your numbers, right), but others might
> argue that supporting AVX-512 has knock-on effects all over the chip. For example, they
> might say the load-store path has to be 4x as large (vs 128-bit) and so on.
>
> So the idea is that since BDW is the last chip to be clearly a 256-bit design,
> you can compare BDW and SKL to get a kind of upper bound on the cost of 256-512,
> including the types of needed-for-512 architectural changes you mention.
>
> Yeah, SKL has some other changes vs BDW, not related to 512, but not *all that many*. Anyway, these push the
> error in one direction: making 512 cost look larger than it is, so it's a useful upper bound (because you
> can say "even under the very conservative assumption that 100% of the added area was 512 support...).

I understand, but I don't think it is relevant alone, there is power too and a complicated trade of, if it was just area one could argue that you could reduce the per core L2 to increase the number of cores, maybe power efficiency says you can't. When running AVX-512 code Intel CPUs reduce frequency, how many non-AVX512 cores would be possible running at that reduced frequency?