Ezek szerint, akkor mégsem annyira elveszett ez az utasításkészlet, mint amennyire a PH-n temetni szokás. valamire csak jó lehet, ha ez alaplapgyártól vissza képesek kapcsolni. Gondolom volt felmérés előtte nem csak úgy hobby-ra kapcsolták vissza, még ha tuningnak számít is.

The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

Furcsa, hogy ennyire nem érdekelte az Intelt, hogy lehetővé teszi az OS-nek, hogy adott szálra, amit az OS csak nagy magra fog tenni, engedélyezze. Legalább is nehezen tudom elképzelni, hogy egy ilyen feature jelentősen növelné az CPU komplexitását.

Ezeket hardverből kell tudnia egy chipnek, igaz?
No, akkor ez hogy történt?
Megtervezték a nagy magokat, aztán rájöttek, hogy a bennük lévő fícsör a kicsikkel nem mén?

A kicsikbe sosem akarták, mert túl pazarló oda. A nagyba (Golden Cove) a Xeon-ok miatt kell. Ezek szerint egyszerűbb így, hogy bent hagyják aztán kiiktatják, mintsem hogy legyen külön nem-Xeon Golden Cove maszkjuk. Aztán végül ki se iktatták...

Szerintem csak annyi a titok, hogy AVX512-vel 300 fölé menne a fogyasztás...

Az megoldhatnák úgy, mint bizonyos Xeonoknál, hogy AVX2/AVX512 esetén kevesebb a max base és turbo freki.

Itt inkább szerintem az lehet, hogy a E magokra nem tudja átvinni az ütemező a folyamatot ha P mag (feature bit)maszkjával indult el.

[ Szerkesztve ]

''Milliárdnyi meggyilkolt csillag sikolya elhal az éj békéjében, és a kétségbeesésnek csak néhány, törékeny, kőbevésett szó áll ellen.''

Ha netalántán ilyen processzort vennék, úgyis az lenne az első dolgom, hogy a fenébe letiltom a E-magokat. Az, hogy esetleg mellette aktiválható az AVX-512 csak bónusz.

Igen-igen, még mindig Win7-et használok, és ha így haladunk még 2030-ban is így lesz.

engem inkább az érdekelne hogy ehhez miért kell a kis magokat kikapcsolni. nem tudjuk kezelni a heterogén utasításkészletet vagy mivan?

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

Nem, az AlderLaket már nem az avx512-vel lehet maxra hajtani mint az előző generációt. Nem is igényli a teljes keretet hozzá. A 12900K max 233 Watt-ot fogyasztott az anandtech tesztje szerint avx512 esetén, ami nem rossz cserébe mekkora teljesítményt ad ezen a részen.

[ Szerkesztve ]

Ja, hogy ebből lesz Xeon is, akkor világos

Semmi köze a vektorizált utasitásoknak a heterogenitáshoz.
A technológia elgondolása sem ujkeletű hiszen az intel 10 éve rendelkezik ezekkel a hardverekkel.
Ez olyan tényleg a titkos fiókból elővett fejlesztés. [link]

Xeon Platinum 8490H,8468H,Ryzen 7500F,Gigabyte B650M K,Xeon Phi,i9 7960X,i9 7920X,Xeon w2135,Gskill royal 4400,Gskill Trident Z,Pico 4,Red Devil 7900XTX,Asrock W790 WS,Fury Pro RDIMM 6000,Z590,Intel Cryo,Intel 11900F,Ryzen 5600,Radeon 7600,Radeon 6800...

Nem szó szerint ebből amúgy, mármint nem ugyan az a die. Csak a die-on a Golden Cover mag rész ugyan az.

Igen jónak tűnnek pedig az E magok Ars-on lévő teszt alapján ([link]). Az alapján kb nagy mag teljesítményének 60%-a 20% fogyasztásból. (Ha pont nagyon épít AVX-512-re valami, az pech.)

Felületesen világos Persze, riszájkling.

azért kell kikapcsolni a kis magot, mert az nem tudja. És ha a nagy magról indul egy avx512-es program, akkor az oprendszer ütemezője, ha átdobja a kis magra, úgy elszáll, mint az állat.

Egyébként netes pletykák szerint sok területet is foglal a sziliciumon az implementálása. Múltkor néztem egy netes "pletyka" videót arról, hogy az amd density procijain (dupla annyi core, kisebb órajellel) is vagy kihagyják vagy pedig 2x avx256 módon hajtja végre, kvázi emulálva, hogy spóroljon a hellyel és a fogyasztással. Teljesítményben úgy nem hoz előnyt, de kompatibilis legalább.

[ Szerkesztve ]

Mondjuk ha onnan indult, akkor eleve tudta az OS, hogy csak nagy magra szabad ütemezni (hacsak nem simán szerencséje volt). Elvileg lehetne azt, hogy AVX-512 az mindig tiltott, kivéve, ha az OS kifejezetten azt közölte a CPU-val, hogy most ezen a szálon szabad. Viszont a tiltás részhez kéne valami AVX-512 enabled flag a CPU-ba hardware szálanként, gondolom én, az meg tán nincs.

Az hogy ennyire nem mentek erre rá, bennem azt veti fel, hogy hosszú távon talán meg is akarják takarítani a lapjáról az AVX-512-et (most csak viszi a tranzisztort), csak most még inkább hagyták úgy, ahogy a Xeonba is kell.

[ Szerkesztve ]

A win maga lehet nem ilyen okos, nem tudja milyen spéci utasításkészletet tud kezelni. A lefordított appban van ellenőrzés induláskor és utána már rosszabb esetben csak ráfut az ismeretlen utasításra, ha átkerült buta magra.
Az alkalmazások meg nem csak azon a magon futhatnak, amin idult, hanem folyamatosan dobálja oda-vissza őket a magok közt, aszerint hogy éppen milyen összterhelés van a rendszeren, hogy az ütemező mit tud (régebben is voltak időszakok, amikor külön driver kellet némelyik procihoz, hogy csináljon hülyeséget a win, későbbre okosították fel az alapból települő ütemezést).

Ha le van tiltva mindkét féle magra az avx512, akkor induláskori ellenőrzések után a program tudja, hogy nem szabad használnia.Vagy, ha megköveteli, akkor kiírja, hogy nem fut.

Gondolom ez a thread director izé lenne majd a "driver" az ilyen felemás intel procikhoz, cska lehet még nincs készen [link] Van az intelnek egyébként proci emulátora is. Régi vason is futtathatnak a fejlesztők legújabb utasításkészletet emulálva, persze marha lassan. Egy kapcsolóval megadható, hogy melyik fajta procit emulálja [link]

Ez a mikrokódos tiltogatás meg régen sem állt messze az inteltől. Például a sandy/ivy bridge procik is tudnának kezelni 8GB-nál nagyobb modulokat, csak nincs engedélyezve a mikrokódban. Valamelyik celeronban meg engedélyezték, mert azt valami ipari eszközben is használják.

[ Szerkesztve ]

Nem kell ellenorizni. Ha a processzor olyan utasitast kap, amit nem tud ertelmezni, akkor illegal instruction exception keletkezik, ekkor az exception kezeloje kiolvassa, hogy jee egy AVX utasitas, es maris visszadobja az utemezo a P magra, majd az elet mehet tovabb. Nem bonyolult ezt megoldani.
A masik lehetoseg, hogy az exceptionnal emulalja az AVX utasitast, amivel teljesitmenyt veszit, de mehet tovabb minden, ahogy volt. Anno ezt a modszert hasznaltak 486-os elotti idokben, ha hianzyott az x87 tarsproci a rendszerbol.

[ Szerkesztve ]

Nyilvan egyszerubb, de ahhoz elemezni kell a programot es bizni abban, hogy futas kozben sem modosit a kodon
Ha exceptionba fut AVX utasitas miatt, onnantol mar megjelolheti maganak, hogy ez nem mehet E magra. Szoval igazabol ez egy indirekt elemzesnek is felfoghato, de tovabbi elonye, hogy ha a program nem fut ra az AVX-es kodreszre, akkor elviszi az E mag is. Azert ez utobbi a kifinomultabb modszer.

[ Szerkesztve ]

Gondolom feleslegesen senki nem öl ilyenbe pénzt. Vagy? Az AMD eleve nem vezette be, mert az AMD esetében nem is volt soha gol az.

The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

az nem úgy van, hogy valami vagy tudja, vagy nem?
a korlátozott fícsörszet mit jelent itt?

Petyke feszegeti az AMD talalgatosban.

az Intel sem minden cpuban csinalta meg teljeskoru tamogatasra, hol adott hozza, hol elvett...

[ Szerkesztve ]

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

Nincs ilyen a munkámban, szóval nem tudom, de ez valószínűleg nem ilyen egyszerű. Az alkalmazás már akár induláskor tudni akarja, van-e AVX-512 támogatás, mert ettől függ, hogy később egyes funkcióknak melyik megvalósítását fogja hívni. Ennek a lekérdezése még nem exception, sőt, valószínűleg azt se tudod, hogy ez le lett kérdezve (mert csak CPUID utasítást hív, aztán franc tudja a visszaadott értékben mit nézett az alkalmazás). Én azt tudom első körben elképzelni, mint minimális megoldást, hogy a felhasználó vagy az alkalmazás telepítő szépen bejelöli az executable-re, hogy allow big core features. Akkor a CPU azt fogja reportálni, azokban a szálakban(!), hogy van AVX-512 (-nek ilyen-olyan subsetje), míg másokban azt, hogy nincs, akkor is, ha véletlenül épp nagy magon vannak. És ehhez kéne a CPU-ban támogatás, mert, gondolom, itt akkor a CPUID utasításnak kéne száltól függően más-más értéket adnia. Vagy, hogy tudjon az OS trappot tenni a CPUID utasításra, és így manipulálni az eredményét.

[ Szerkesztve ]

Na igen, ha olyan egyszerű lenne, akkor nem lenne ennyi probléma körülötte.
Az illegal instruction kezelést csak a programon belül vagy compiler szinten lenne esély kezelni, hogy ott minden művelet előtt mentsen egy ismert állapotot. Ráadásull lehet atomi művelet szinten kellene levédeni, nehogy egy vizsgálat után kerüljön át más képességű magra. Ha ezt meg lehet csinálni, akkor is nagy teljesítmény vesztést okozna, miközben pont teljesítményigényes feladathoz kell a spéci utasításkészlet.
Ha exceptionre engedik futni, akkor meg proci szinten is úgy kéne ezt kezelni, hogy adatvesztés és ismeretlen állapot ne léphessen fel.

Az os üzemező meg ennél sokkal butább most. Az az intel director cucc lehet csinál majd valami extra vizsgálatokat, hogy felismerje milyen magon szabad futtatni a programot. De lehet az is butább ennél és csak azt nézi, hogy közös cache vagy egy féle magok közt dobálja át a processzeket. (Ahogy az egy tokban több egymás mellé tett procis megoldásoknál is kellett arra figyelnie, hogy ne tegye át másik blokkra, mert akkor a cachet is át kell másolni).

A drm bugzásos baja kapcsán is érdekes, hogy egészen friss játékok is szenvednek tőle és le kell tiltani a kis magokat, hogy jól működjenek patch nélkül. Még nem sok infó van erről, de az, hogy win11 -re ígérnek os fixet, 10-re meg nem.... lehet ezzel próbálják majd átterelni win11-re az embereket az ms-nél. Ahogy régen a dx12-vel kényszerítették a játékosokat váltásra.

[ Szerkesztve ]

a hw exception regota ismert es hasznalt modszer, Reggie emlitett koprocis megoldasa eleg jol muzsikalt ; es szvsz elvileg ide jo is lehetne. Marmint azokra a programokra, amik nem tartalmaznak az avx hiany esetere alternativ kodutat. Akkor tutti jon a kivetel. Atkerul a nagymagra, utemezo megjegyzi, hogy ezt nemkene visszatenni a kicsire, mindenki happy.
A probelma inkabb az, amit DDekany irt, hogy a jelenlegi szoftverek az elejen egyszer megnezik, hogy van-e avx vagy nincs, es ezutan mar a vizsgalat alapjan kitalalt kodutat fogjak vegrehajtani.

Ha a nagymagon indul a szoftver, akkor megallapitja, hogy a szukseges utasitaskeszlet megvan, ha atkerul kismagra, elso kivetlnel gyorsan visszakerul, es jól fog mukodni.
Haviszont kezdetben a kismagra dobja az utemezo, akkor azt fogja latni, hogy nincs avx, es hiaba kerul at a nagymagra nem fogja hasznalni. ( azaz ott is lassu lesz. )

amugymeg a toredezettsege es az elterjedsege miatt ( ugye az Intel kezdetben csak a csucs cpuira engedelyezte ) alig van szoftver, ami kifejezetten igenyli, szoval ezzel a letiltassal kb. nemsokat vesztettek, ( perpill a Zenek is eleg jol elvannak nelkule ) viszont valoszinuleg az ms szoftveres reszlegenek megsporoltak 1-2 honapot meg par ősz hajszálat. Utóbbiban nemvagyok biztos, lehet az idők során már amugyis kihullot nekik mind.

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

értem én, hogy meg lehetne csinálni. De így működik most? Szerintem nem. Ha így működne, akkor nem kéne tiltogatni. Szerintem te is ilyesmit írsz.

Kicsit összeesküvéselméletesen... az ms és az intel számára is jól jön ez a töketlenkedés. Hogy ösztönözzék az embereket, hogy win11-et akarjanak használni és vegyenek új gépet, lehetőleg intel procival. Mert ms ütemezője problémás lehet a nem inteles, nem win11-es új heterogén gépeken.

[ Szerkesztve ]

Nos, ilyen esetben crash sem lesz, hiszen azt hiszi, hogy nincs AVX-512. Tehat nem lesz problema, ha P-rol E-core-ra lesz atdobva. Tehat pont ugy fog mukodni, mint ahogy most is. Aztan majd okosodhatnak a programok es figyelembeveszik ezt a mukodest is a CPU azonositasanal, hogy ne zarjak ki az AVX-et, vagy az OS, hogy atverje a CPUID-t.

#30 azbest: Nem azert kell tiltogatni, mert nincs ra megoldas, hanem mert ez a kenyelmes megoldas az intelnek. Latszik, hogy ki akarjak vezetni az avx512-ot ebben a termekkategoriaban, de kozben nem akartak teljesen ujratervezni a P-core-t.

[ Szerkesztve ]

Igen, ezt mondtam, hogy alapból nem lenne AVX-512, de annyiban lenne jobb mint most, hogy ha valakinek tényleg hiányzik, akkor még vissza lehetne kapcsolni alkalmazás szinten. Aztán mindenki eldöntheti, hogy neki abban az alkalmazásban megéri-e az E-s magok elveszítése az AVX-512-ért cserébe.

Amúgy ha igazán komolyan vennék, akkor már direkt heterogén CPU-kra felékszült alkalmazás verziókban lehetne, hogy "bool avx_512_available = some_os_api::stick_to_core_that_supports_feature_if_avilable(AVX_512);", és akkor az alkalmazásnak csak az ezt hívó szála fog big core-hoz ragaszkodni, és a többi továbbra is mehetne little-re is. Szóval CPUID-vel piszmogás helyett az OS-től kéred le a feature elérhetőséget, és egyben kéred az OS ütemezőjét, hogy csak oda rakjon ahol az elérhető, ha valahol elérhető.

De mint mondod, valószínűleg ki akarják totál vezetni az AVX-512-t desktopon, hogy felszabaduljon a helye valami hasznosabbra, ezért nincs ilyen.

[ Szerkesztve ]

szálankent durva lenne kezelni az avx-et, mikor altalaban meghiv az ember 1 millio threadet, aztan a hardver leosztja ahogy tudja,
az egyetlen ertelmes megoldas erre a problemara az, ha az (E) magok is kepesek vegrehajtani az avx-et, persze tobb ciklus alatt , ehhez csupan par kilobyte microkod kell

azt mondjuk nem ertem hogy az ilyen szeles vektoregyseg utasitasokat miert nem a gpu reszen hajtja vegre , duplan rarakni a chipre botorsag,
es akkor az osszes mag tolhatna ezerrel
persze az is teny hogyha az intel mellett van egy nvidia, akkor az avx-nek gyakorlatilag semmi ertelme nincs, az nvidia letolja az utrol , kb mint egy kamion vs parasztszeker stilusban

A szálakat az OS osztja le a magokra, és szálak közötti időmegosztásos kapcsolgatás is az OS feladata (kivéve a hyperthreading esetében, de az OS szempontjából 1 helyett 2 mag lényegében). Szóval ha lehet az OS-el közölni, hogy ezt a szálat csak nagy magra lehet, akkor nincs ebben semmi kezelhetetlen. Csak gondolom nem akarják az egészet desktopon.

Mert az AVX512 SIMD, a GPU pedig SIMT.

újabb Linux AVX-512 tesztek

"Intel Core i9 12900K "Alder Lake" AVX-512 On Linux" ( 7 November 2021 )
https://www.phoronix.com/scan.php?page=article&item=alder-lake-avx512&num=2

Fogyasztás ..

Teljesítmény:

A probléma:
- A programok nagyon kis része használja ki az AVX-512 -es utasításkészletet.

Mottó: "A verseny jó!"

Kicsit összeesküvéselméletesen... az ms és az intel számára is jól jön ez a töketlenkedés.

Intel korában is az OEM-eken keresztül igyekezett biztosítani a piaci részesedését, a DIY szegmens nem prioritás. HP, DELL, Lenovo és a többi parter kínálatában ott lesznek a hibrid cpu-val szerelt gépek, az átlag felhasználásra ezek továbbra is megfelelnek és oda belátható időn belül nem kell az AVX-512 támogatás.

MS részéről a piaci dominancia a fókusz, az OS eladásból származó bevétel fontos de nem ez a prioritás.
Mind az Intel mind pedig az MS horizontális vállalat amelyek az OEM gyártókkal együtt alkotnak egységet.

Az egész DIY egy szükséges rossz ami csak púp mindenkinek a hátán. Intel-nek extra logisztika és marketing költség, MS-nek hatványozott kompatibilitási tényező az OEM gyártóknak plusz egy "versenyző".

szuper, már vártam a teszteket

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