Szerintem fontos szétválasztani dolgokat. A heterogént lehet úgy csinálni, hogy az ISA azonos legyen és eközben szinte minden érved a heterogén mellett érvényes marad.
Az AVX512 ISA támogatás valójában csak frontend kérdése. Az utasításdekóder, az adatfüggőség feloldó, a dekonfúzió-kezelő, stb. rész kell, hogy támogassa a konkrét opkódokat és az EVEX operandus-formátumot. Ez nem nagyfogyasztású vagy sok tranzisztort igénylő dolog. Illetve maga a frontend szekció egésze az, de a meglevő rendszerbe felvenni új utasítások támogatását már nem tesz sokat hozzá.
A backend támogatást (a tényleges végrehajtóegységeket) már nagyon széles tól-ig tartományban lehet kiépíteni. Szélsőséges esetben akár semmit nem kell csinálni, mert a meglevő (keskeny) egységeken, sok ciklusra felbontva is végre lehet hajtani. Olyannyira, hogy az Intel csinálta is, pl a hírhedt AVX512VP2INTERSECT utasítás mikrokódból volt megvalósítva. Vagy a Skylake (és egyéb korai lake-eken), a powersave állapotból annyira hosszú ideig tartott még beröffenteni az 512bites egységeket, hogy átmenetileg a processzornak a kisebb végrehajtóegységeken kellett futtatnia ezeket az utasításokat. Nem lesz kifejezetten gyors, de nem növeli meg a fogyasztást (sőt..., erre visszatérek) és nem növeli meg a kis magok méretét sem. Aztán lehet fokozatosan haladni, mondjuk 4 ciklusos, 2 ciklusos és a teljes 1 ciklusos végrehajtásig, egyre nagyobb végrehajtóegységeket igényelve, egyre nagyobb magokban.
Valójában ez növeli a hatékonyságot. A fő célja az egyre szélesebb vektoroknak az, hogy "darabra" kevesebb utasítás kelljen ugyanahhoz a feladathoz, ezért a CPU frontend terhelése csökken. És főleg a frontend az, ami rosszul skálázódik. Ráadásul nem végez közvetlenül hasznos munkát (persze a frontenden sok múlik, hogy a tényleges végrehajtóegységek minél jobban ki legyenek használva), de ettől még ez egy szükséges rossz, amolyan "rezsi" a processzorban. Ezért volt, hogy az AMD már a Zen4-nél is jelentős (+20-30%) eredményeket tudott elérni a részleges, csak 256 bit széles AVX512 megvalósításával, az AVX256-hoz képest.
A másik, hogy AVX512 végrehajtása keskeny végrehajtóegységeken nem annyival lassabb, mint ahány ciklusra kell felbontani. A pipeline manapság van simán 20-30-mégtöbb órajel hosszú. Ebből tippre a data fetch, az execute és a data writeback lépéseket kell többször ismételni, ha nem elég széles a végrehajtóegység. Ha egy teljes szélességű egységgel egy bizonyos művelet 30 órajel, akkor egy fele széles egységen lesz mondjuk 36, egy negyedszéles egységen mondjuk 42 órajel a teljes végrehajtási idő. Az áteresztőképesség persze feleződik, vagy negyedelődik. De ha a kódban nem sűrűn, szoros ciklusmagban vannak használva ezek az utasítások (512bites vektoros utasítást azonnal másik 512bit széles követ), hanem szórványosan bekeverve normál utasítások közé (pl a glibc különféle string ill memcpy műveleteknél inkább ez a helyzet), akkor a latency a meghatározó, nem a throughput.
Szóval én azt gondolom, hogy igazából nincs valós elvi indok rá, hogy a kis magok ne támogassák, legfeljebb nem lesz gyorsabb tőle a kód. De valószínűleg a frontend terheléscsökkenése miatt még így is nyersz valamennyit a fogyasztáson.