engem továbbra is az érdekelne, hogy minek gyártottak egyáltalán ilyen procit ha utána letiltanak egy nem kis lapkaterületet felemésztő részt.

miért nem készült ehelyett kétféle proci, a heterogén magos rendszer AVX512 nélkül, az AVX512-s meg E-core nélkül.

továbbá az sem világos számomra, hogy miért ne lehetne egyszerre használni a kettőt. értem, az E magok utasításkészletéből hiányzik, de mi van akkor? NOP-ra fut ha E-magon próbál valami avx512-t hívni, de ezt szerintem OS szinten egy CPU flag bindinggel lehetne kezelni.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Almost Vector eXtensions.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

Szerintem a válasz ott lehet valahol elásva, hogy nem a procit tervezték így, hanem a magot. Azt meg azért tervezték így, mert van olyan felhasználási terület, ahol (még) használják ezt a fícsört. De nem akartak különböző magokat tervezni sok helyre, így ugyanazt használják mindenhol. Ezért lehet pl.
Aztán hogy miért próbálják meg tiltani? Mert lehet, hogy a Win nem tudja rendesen lekezelni, és lehet, hogy nem egy 'nop'-ra futna ki, hanem egy nagyobb hibára, amit akár egy hacker ki is használhatna. De lehet, hogy azért is, mert E-magokkal nem ugyanaz a teljesítmény, és ezért beperelnék őket (amcsiba már mindenért is perelnek). És ezek is csak példák. Lehet, hogy van más ok is (vagy csak más ok van ). Nem látok mögéjük, és nekem sem tetszik, hogy tiltogatják a lehetőségeiket próbálgató alaplapok tulajdonosainak lépéseit, de attól még lehet észszerű ok is a háttérben, nem mindig csak a 'gonosz'.

Na de mit oldana meg ha NOP-ra fut ahelyett, hogy végrehajtana egy AVX512-es utasítást? Néhány NOP nem fogja végrehajtani a kimarad utasítást. Nyilván azért hajt végre valamilyen AVX utasítást a program, mert valamit szeretne kezdeni az eredményével. Az meg meglehetősen bonyolult volna elemezni valamilyen programszálat előre, hogy tartalmaz AVX 512-es utasítást vagy nem és ennek figyelembevételével is döntene az erőforrás kezelő, hogy egy programszál futását E vagy P magra teszi. Az igen csak lelassítaná a dolgokat, ha még gépi kódot is kéne előre elemezni felhasznált utasítás készlet szinten, mielőtt elereszt a program szálat valamilyen magra. Aztán, hogy miért nem raktak AVX512 utasítás készletet az E magokba nem tudom, Vélhetően valamilyen teljesítmény oka van és a mag energia fogyasztásához kötődik.

erre írtam a CPU flagginget. a folyamatról ha előre lehet tudni hogy hívni fog-e avx512-t akkor a kernel rögzíteni tudja hogy csak P magon fusson.

a NOP-ot csak mint ilyen edge case írtam.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

ugy lehetne megoldani, hogy a kismagon az avx utasitas dob egy kivetelt ( nevezzuk mondjuk "no avx extension" kivetelnek), amit a kernel lekezel olymodon, hogy attolja nagymagra a taszkot. csak hat ehhez bele kellene nyulni a windows a linux es az osszes os magjaba, es talan visszamenolegesen nem is lenne teljesen kompatibilis, mert mivan, ha mar nem supportalt kernelen, mittomen win7 alatt akarok avx512 utasitasokkal megtuzdelt szoftvert futtatni. ( tudom, nemmegy a win7 az uj vasakon, de az elmeleti problema letezik. )

[ Szerkesztve ]

Első AMD-m - a 65-ös - a seregben volt...

ez indokolatlanul bonyolult IMO.

én úgy gondolom hogy az általam felvetett megoldás sokkal kevesebb bolygatást igényel a már meglévő dolgokban. egyébként meg ha nem létező utasítást próbál hívni a program akkor miért kéne az eddig megszokott viselkedéstől eltérően reagálnia?

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

azert, mert mar maga a proci is elter az eddig megszokottaktol, amig az Alder meg nem jelent egyforma magok voltak, ha a big-littlen feluil meg ugy is derivaljuk, hogy az eros magban van avx512 a kicsiben meg nincs, megis mindket verzio aktiv az minden, csak nem az eddigi kozmegallapodas.

[ Szerkesztve ]

Első AMD-m - a 65-ös - a seregben volt...

Ez egyérdekes kérdés

Inkább azt kérdezzék miért nincs szobrom, mint azt, hogy miért van...

Igen, de eddig azt lehetett előre tudni, hogy a proci támogattja-e az AVX512-t. Tehát a felhasználói programok tudták a rendszerről, hogy van-e AVX512, és nem a rendszer tudta a programról, hogy használ-e AVX512-t. És ennek logikusán nincs is máshogy értelme, mert csak a program tudhatná magáról, hogy 8e maggal vagy AVX512-vel fut le gyorsabban. Rosszul adná ki magát, ha bepipálod az AVX gyorsítást, és ennek hatására 50%kal lassabban fut le a programod, mert csak marginális részben használja az AVX512-t.

a rendszernek nem dolga a programok működését ismerni. erre való a kernel hogy az ilyen dolgokat leossza, hogy egy olyan futtatható állomány ami fog avx512-t hívni, annak a threadje ne kerüljön E-magra. ezt egy flaggel meg lehet oldani.

azt meg nem értem hogy miért futna lassabban. mármint hogy nem a technikai részét, abban szerintem csak simán nincs igazad, hanem az egész elgondolást emögött a feltételezés mögött nem értem.

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Van 8E magod és 8P magod. Bármely programot, ha lefuttatsz, akkor vagy 16 szálon futtatod AVX512vel, vagy 24 szálon, de AVX512 nélkül. Ha egyáltalán nem használsz AVX512-t, akkor nyilván 24 szál jobb, ha nagyon használod, akkor meg gondolom a 16. A felvetésem arra vonatkozott, hogy mi van, ha a munkafolyamat egy része használ csak AVX512-t? Szóval mi van, ha nem nyerek annyit az avx-es gyorsításon, mint amennyit a többi helyen vesztek a kisebb párhuzamosításon. Lehet, hogy ez nem reális feltételezés, vagy meg lehetne oldani jobb programszervezéssel (AVXes és a nélküli dolgok külön szálba szervezése). De mi van ha az egyszerű programozó rosszul adja meg (bepipálja az AVXet, pedig nem is használja a kódjában), ő csak annyit fog látni, hogy AVXel lasabban fut, mintha kiszedi a pipát...