Any feature that's a serious benefit for raw performance takes up serious area. At Intel's volumes, it's better to produce a different (and smaller) die for performance-based market segmentations.
Expect this to be used for features that are comparatively cheap in terms of area but valuable for enterprise. Virtualization features, ECC, that sort of thing.
This will slow the adoption of those features in software ecosystems since many developers still quite reasonably focus on stuff that works on their local machine.
Yep, Intel clearly hasn't learned a single thing from the disaster that has been price segmentation on features like AVX-512, the result is the vast majority of software never bothering to use it, because it can't be guaranteed to actually be present.
I'd argue exposing the IEEE 754 binary64 (aka f64; aka double) FMA unit's `((u52 * u52) & (1 << 51)) + u64` and `((u52 * u52) >> 52) + u64` (low half/high half, respectively) in the AVX-512IFMA instruction set was quite effective for the cost being comparatively cheap bypassing of exponent/sign handling and corresponding instruction decoder additions.
Note: these help for wide multiply, as needed most prominent by ed25519 and RSA. They do apply for "just" 256bit vectors using 4 lanes of 64bit (where multiplicands are just the low 52bits), without the AVX-512-typical clock penalty.
In similar spirit, it would have been nice to get emulated AVX-512 on AMD and Intel's E-cores, as it uses just one instruction to process twice the width, reducing the frontend throughout requirements. Also said AVX-512IFMA is rather nice, regardless of vector width.
Intel seems to be able to economically produce Core-series mainstream chips that contain huge but disabled AVX-512 units. I think the die area concern may not be so important.
True, that's quite a puzzling situation. It must be the case that the bean counters at Intel would prefer to have the reduced area for those products because it certainly affects margin.
Was Intel's design team really unable to make that happen at a reasonable cost? Were they trying to build a product that supports AVX-512 but failed? I wonder if we'll ever know.
Expect this to be used for features that are comparatively cheap in terms of area but valuable for enterprise. Virtualization features, ECC, that sort of thing.
This will slow the adoption of those features in software ecosystems since many developers still quite reasonably focus on stuff that works on their local machine.