intelnek mind1, ha már úgy is optimalizálni kell a big-little felépítés miatt...

The human head cannot turn 360 degrees... || Ryzen 7 5700X; RX580 8G; 64GB; 2TB + 240GB + 2TB || Samsung Galaxy Z Flip 5

Meg lehet oldani erőből: a programozók majd olyan programot írnak, ami optimális a HBM-nek, vagy a felhasználó kikapcsolja annak a használatát, ha több hátrányát látja mint előnyét. Lényeg az, hogy a HBM benne van a processzorban, és az az ügyfélnél van, onnantól a többi az ügyfél/programozó gondja.

Naná, a programozók pont arról híresek, hogy imádnak random hardverváltozásokra optimalizálni.

Pont azt taglalja a cikk, hogy olyan megoldás kell, ami nem igényli szoftverek módosítását.

[ Szerkesztve ]

#tarcsad

Az irónia detektorotok látom nem működik..

A cikk arról szól, hogy úgy kellene megoldani a problémát, de egyenlőre azt nem tudjuk, hogy intel-nél ez prioritás-e.

[ Szerkesztve ]

szervernél hol lesz big.LITTLE?

Nem állítom, hogy minden szerverprocesszor big.LITTLE lesz, de szerintem is lesz.
A nagy magok valószínűleg mindig csak ~30%-kal magasabb IPC-t fognak tudni + a 20%-kal magasabb frekvencia, ami viszont szervereknél nem különösebben érdekes, mert valószínűleg mindkettő 3-3.5Ghz környékén fog ketyegni.
Viszont 1 nagy mag helyén 4 kis mag fér el. Az 1 nagy mag 2 szálon 1.7 kismaggal ekvivalens.

Találgatunk, aztán majd úgyis kiderül..

Engem a hideg kiráz ettől a big-littletől

Működik az, ha helyett valaki szmájlit rak...

#tarcsad

Szerintem úgy, hogy prioritás a processzor közel teljes kiterhelése, mellette a tartósan alacsony késleltetés, úgy nem sok értelme lenne. Ne felejtsük el, hogy a koncepció a mobil vonalról jön, ahol pont a szakaszos terhelés a döntő, és amikor a kis magokat használja lehet akár másodpercekben mérhető a késleltetés, nem veszi észre senki.
Jelenleg, ha van olyan feladatod aminek 4x több kis mag jobban fekszik, akkor veszel hozzá alacsony órajeles, sokmagos processzorokat, és átirányítod arra. Ez a big.LITTLE a svájci bicska esete, ide meg szerintem céleszközt vásárolnának szívesebben adott feladatkörre. Másik probléma a skálázhatósága: Látszólag lehet hogy rugalmas, de mennyi socketet kell kifizetni pluszban, ha kiderül hogy kell még 128db nagy mag egy feladat okozta plusz terheléshez. Veszel még 4-8 socketet vagy kettőt?

Nem állítom, hogy nincs olyan mixed terhelés ahol ez jó lehet, megfelelő szoftveres háttér mellett, de a java tényleg nem ezt kívánja.

[ Szerkesztve ]

Érdekes cikk. Köszi.

"Ne felejtsük el, hogy a koncepció a mobil vonalról jön, ahol pont a szakaszos terhelés a döntő, és amikor a kis magokat használja lehet akár másodpercekben mérhető a késleltetés, nem veszi észre senki."

A heterogén magok használatának koncepciója lehet, hogy onnan származik, de szerintem lényeges különbséget jelent, hogy hol mi a cél a különböző típusú magokkal.
A mobil esetén tényleg az a célja a kis magoknak, hogy legyen valami, ami a nem időkritikus folyamatokat a lehető legkisebb energiabefektetéssel elviszi.
Az Intel kis magjainak viszont egyáltalán nem ez a célja.
A kis magok célja a magas teljesítmény optimlális energia és tranzisztorbefektetés mellett
Ellentétben ezzel a nagymagok nem kímélik az energiát és a tranzisztort és a legmagasabb Single Thread teljesítményre törnek.

Nem teljesen értem a szkepticizmust
"Másik probléma a skálázhatósága: Látszólag lehet hogy rugalmas, de mennyi socketet kell kifizetni pluszban, ha kiderül hogy kell még 128db nagy mag egy feladat okozta plusz terheléshez. Veszel még 4-8 socketet vagy kettőt?"

Egyrészt ha neked kell még 128db nagy mag, akkor olyan szerverprocesszort fogsz venni, amiben van 128 nagy mag.
Másrészt egy ilyen kérdés már ma is ugyanúgy felmerülhet. Ha ennyire késleltetéskritikus a programod, hogy minden szálnak mindenképpen a lehető legnagyobb teljesítménnyel kell futnia, akkor már fel kell tenned magadnak a kérdést: 2 socketben veszel 128db magot, vagy 8 socketben. Vannak olyan EPYC processzorok, amelyek alacsony magszámmal de 1Ghz-cel gyorsabban futnak, mint 64 magos társaik. És ha tutira mész, akkor letiltod az SMT-t is.
Ha innen nézed, akkor a 64 magos szerverprocesszor a 16 magoshoz képest ugyanúgy alacsonyabb teljesítményű "kis" magokból áll.

Én nem állítom, hogy minden workloadhoz jó lesz.
Csak azt, hogy ha pl van ma egy 32 magos processzor, akkor annak többszálas teljesítményét elérheti egy olyan big.LITTLE processzor, ami 8 nagy magból és (mondjuk hasraütök) 48 kis magból áll. 64T vs 64T továbbra is.
Eközben a 32 magos processzor 32 magnyi helyet használ a 8+48-as pedig ~20 nagy magnyi helyet, tehát költséghatékonyabb lehet az előállítása, miközben nem kellett lemondanod az egyszálas teljesítményről sem.

Találgatunk, aztán majd úgyis kiderül..

A big.little desktopra való, nem szerverprocesszorra.
Desktop (+mobil) terhelése olyan, hogy hol a leveleidet olvasod, hol böngészel, hol videót nézel, hol pedig játszol. Ez mind különböző terhelést, különböző igényt jelent a processzortól.
A szerver viszont nagyjából azonos feladatot végez rengeteg szálon. Ha nő a terhelés, több szálon, ha csökken kevesebben. Itt a szálak gazdaságos elosztása a kérdés, ne a heterogén felépítés.

Azert nem teljesen. Van jopar alapfeladat, amit ki lehetne kisebb magra szervezni es nem kell taskvaltassal pazarolni az erosebb magokat, illetve azok L1/L2 cachejeit osszeronditani.

Azért a big.little támogatását megoldani nagyobb probléma, mint amit az L1/L2 cache összerondítása okoz.
Főleg, ha utólag kell megoldani legacy kódon és a magok más típusúak (in-order / out-of-order).

"A big.little desktopra való, nem szerverprocesszorra."
Szerintem még oda se. Max mobil.

Legacy kodnak csak az affinitasat kell allitani, aztan kesz.

big.little nem nagy problema, ha a kodoknak csak a big magon kell futni es a kernel alapszolgaltatasok, stb. futnak a little magon.

Azert linux kernelt sem veletlen szokas full dyntick+cpu isolation-nal forditani nagy szamitasigenyu feladatokhoz.

Azt jön az OS ütemező ami elkezdi "pakolgatni" a futó folyamatokat ide-oda, és az eredmény: a mag sose alszik...
De ez probléma lehet különböző clusterben levő CPU-knál is, mert a cache tartalmat folyton másolni kell majd...

The human head cannot turn 360 degrees... || Ryzen 7 5700X; RX580 8G; 64GB; 2TB + 240GB + 2TB || Samsung Galaxy Z Flip 5

kifejtenéd kérlek?

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

Én .net párhuzamos programozásban vagyok járatos és én úgy látom, hogy a .net jelenlegi parallel frameworkjét szépen haza fogja vágni, ha megjelennek jelentősen eltérő teljesítményű szálak a szálkészletben. Nyilván lehetne erre reagálni a jövő keretrendszereiben, de a jelenlegiekhez a microsoft sosem szokott hozzányúlni érdemben és szerintem nem is nagyon fog. Úgyhogy kíváncsi leszek mi lesz a jelenlegi erre épülő rendszerekkel.

azért remélem érzed hogy ez a labda alapvetően inkább a szoftveres oldalon pattog...

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

Szerintem azért manapság a legtöbb programozó inkább valami magasabb szintű programnyelvet használ, ami nem igazán teszi lehetővé pl a szálak megkülönböztetését.
Meg a saját oldalamról nézve (azaz szoftvergyártó) egyáltalán nem érzem semmi értelmét gyengébb szálak jelenlétének. A programom szempontjából semmi előnye nem lesz annak ha bármit is ilyen szálakon futtatok. Viszont hátránya simán lehet a szinkronizáció során, amikor be kell várniuk egymást a szálaknak. Amikor pedig valaki azzal jön, hogy de gyenge szálakból sokkal több lehet majd és ez előny lesz, akkor mindig arra gondolok, hogy most már 8 erős szál simán elérhető, de sokan még mindig nem használják ezt se ki.

Az energiatakarékosság desktopon vagy notebook esetén meg sosem számított egy program előnyének, mivel az mindig a gép tulajdonságaiként jelenik meg a felhasználók fejében.
Ha tovább bírja a laptop akkuról akkor biztos jobb a gép. Senki sem fogja azt mondani, azért bírja jobban mert én olyan programot használok ami ebben segít, tehát tök felesleges erőforrást ölni egy programba ami ebben jó.

Desktopra azért fog jönni, mert mobilba hozza az Intel, és ez egyenes utat jelent a desktopba.

Egyébként desktopban én sem látom értelmét.

#tarcsad

Szerintem Intel most pont úgy keveri össze a mobilt (telefon) a notebookkal és desktoppal, mint anno a Microsoft tette ezt a win 8-nál.
Telefon esetén marha jó az érintőképernyő meg a kicsi és nagy mag, mivel a telefon jellegéből fakadóan csomó időt csücsül az ember zsebében miközben várja, hogy üzenet jöjjön vagy hívás. Ilyenkor tök mindegy, hogy 1 másodperccel később csippan be, viszont nagyon nem mindegy, hogy 3 óra alatt merül le, vagy 24. Ráadásul az oprendszer ezt gyönyörűen ki tudja használni.
De ilyen üzem még még notebooknál sincs nemhogy desktopon. Ha az ember nem használja, lecsukja és megáll minden. Nincsenek futó háttérfolyamatok ahol ennek tényleg valódi haszna lenne.

[ Szerkesztve ]

Nem voltam egyértelmű: mobil alatt a mobil számítógépeket értettem, nem a mobiltelefonokat. Egyébként egyetértek a véleményeddel.

#tarcsad

Pedig elég valószínű, hogy generációról generációra a kis magok számát fogja növelni.
Szerintem 12 mag helyett 8+32 izgalmasan hangzik. Sőt 16 nagy mag helyett 8+64 méginkább HEDT témakörben.
A számok itt ugye nem teljesítményt jelentenek,.hanem tranzisztor igényt. MT teljesítményben 4 kismag 1 nagymag kétszeresét is hozhatja.

Találgatunk, aztán majd úgyis kiderül..

Egyébként visszatérve a cikk témájára: a HBM -nek miért nagy a késleltetése, ha egyszer a procira van integrálva?

A probléma továbbra is az, hogy gazdaságosan akkor fut a szerver, akkor termeli idő egység alatt a legtöbb pénzt, hogy ha a TDP lehetőleg ki van használva, addig a szintig, ameddig csak zavartalan a szolgáltatás minősége.

Egy olyan processzornál ahol 8 nagy mag "egyenlő értékű" 36db kicsi maggal TDP szinten, és van benne összesen 48 kicsi és 8 nagy, ott kb.:~62,5%-os TDP-ig működik teljesen zavartalanul a szálak-erőforrások közti váltogatás. Fölötte, ahol a 36 kicsi és a 8 nagynak harcolnia kell a számukra fenntartott TDP keretért, már nő annak az esélye, hogy késleltetés tüskék keletkezzenek. Addig ameddig egy hagyományos processzornál ez mondjuk 90%-os TDP fölött jön elő.

Röviden tök nagy biznisz lehet a szolgáltatás minőségét kockáztatni azért, hogy egy olyan működési tartományban lehessen gyorsabb és egyszerre energiatakarékosabb a leendő szerver processzor, amiben lehet ,hogy nem is óhajtják azt használni.

Ha azt mondanák hogy tudunk 64 magos processzort csinálni ami 280W-ból sok szálra optimalizált terhelésnél olyat mutat mint egy 40 magos 400W-os akkor azt mondanám hogy OK. De ezt a marketing osztály gyomra nem venné be..

[ Szerkesztve ]

"Egy olyan processzornál ahol 8 nagy mag "egyenlő értékű" 36db kicsi maggal TDP szinten, és van benne összesen 48 kicsi és 8 nagy, ott kb.:~62,5%-os TDP-ig működik teljesen zavartalanul a szálak-erőforrások közti váltogatás. Fölötte, ahol a 36 kicsi és a 8 nagynak harcolnia kell a számukra fenntartott TDP keretért, már nő annak az esélye, hogy késleltetés tüskék keletkezzenek. Addig ameddig egy hagyományos processzornál ez mondjuk 90%-os TDP fölött jön elő."

Én nem vagyok a téma szakértője, nem foglalkozom szerverekkel, tehát ebben nincs tapasztalatom.
Talán épp ezért nem értem, de szeretném megérteni.
Hogy jött ki ez a 62.5%?

A 8 nagy mag és a 36 (vagy akárhány) kis mag pont ugyanúgy ugyanazon a TDP kereten osztozik, mint homogén magok esetén. A homogén magok teljesítménye sem egyforma, nem ugyanolyan a turbó frekvenciájuk, sőt egyáltalán a turbó önmagában egy varianciát okozó tényező. Ugyanúgy elmondható, hogy 50-60%-os TDP keretig tud turbózni egy-egy magon, de ha ennél nagyobb kihasználtságnak teszed ki, akkor az alapfrekvenciához közel tud csak ketyegni a mag. De ugyanúgy harcolnak a magok a TDP keretért, hogy turbózhassanak.

Én nem igazán látom a különbséget eközött, meg aközött, ahogy pl az 5950X össze van rakva. Az két külön CCX, még csak L3$ sem köti őket össze (thread hopping) Az egyik lapka kiváló minőségű, magasra tud turbózni, a másik lapka általában közepes, azért van, hogy ha az összes szálat használod, arra is rá tudja osztani. Nyilván a TDP keret miatt a második lapka aligha fog max frekvencián járni, hanem megmarad 3.5-4Ghz táján.

Az igaz, hogy a két különböző minőségű zen lapkán levő magok maximális teljesítménye között lényegesen kisebb különbség van mint az ADL nagy és kis magjai között. De a programoknak már ma is meg kell találni, hogy melyik az jobb mag / jobb CCX.

Találgatunk, aztán majd úgyis kiderül..

Pollack's rule

Ez talán szemléletesebb: [link]
De mit akartál ezzel mondani?

Találgatunk, aztán majd úgyis kiderül..

"De olyat sosem látsz, hogy..."

És az biztosan azért van, mert a hardver odafigyel, higy ne essen szét a négy szálat használó program?

Nem lehet, hogy ha egy CCX-en belül 4 magot terhelsz, akkor már nem is tudna külön frekvencián menni, vagy mert a tdpbe nem férne bele, vagy mert nem is.tudja külön szabályozni. Ha jól.emlékszem magonkénti feszültségszabályozást csak a zen3 kapott.

Biztosan így van az Intelnél, turbo boost 3.0 mellett is?

Találgatunk, aztán majd úgyis kiderül..

48x=TDP
(TDP/48x)*((36x/2)+12x)=0.625TDP
(egy magra eső TDP)*(egyensúlyi állapotban aktív magok száma)

Ha innen közelítjük meg ahogy leírod, akkor a normál processzornál a terhelés növekedésével csökkenő a magok órajele, itt meg elképzelhető olyan szervezés, hogy 4-5 kicsi magot ki kell kapcsolni ahhoz, hogy egy nagyot be lehessen kapcsolni, vagy fordítva, hogy át lehessen szervezni az energia felhasználást. Azt kell mérlegelnie a logikának, hogy ez a lépés megéri-e. Ha meg "kézi vezérléssel" prioritást adsz egy olyan szálnak, ami miatt 1 db nagy magot "be kell kapcsolni minden áron" ilyenkor +2-(4..5) szállal fog gazdálkodni a processzor a következő váltásig.
Itt az energiagazdálkodás szintjén, meg lehet azt fogalmazni, hogy tovább esetleg nem éri meg az óra-jelet folyamatosan fel-le léptetni, mert arra ex-has 10-10 db üres órajel ciklus a büntetés minden lépésnél. Inkább olyan magot kell tervezni, ami kizárólag fix 5Ghz(nagy) és fix 3Ghz-re(kicsi) van optimalizálva jelterjedésileg és legyen elvárás, hogy 5Ghz és 3Ghz-en tartson el 10 órajelciklusig, amíg teljesen be vagy ki kapcsolható, ne 600Mhz-en! Az effektív 600Mhz-et úgy is el lehet érni, hogy a 3Ghz-es mag 20%-os kitöltési tényezővel üzemel, ekkor az idejének 80%-át kikapcsolva tölti.

[ Szerkesztve ]

Próbálom megérteni a számolásodat.

Ugye azt mondtad, hogy van egy heterogén cpu, amiben van 8 nagy mag és 48 kicsi
És 8 nagy mag fogyasztása megegyezik 36 kis magével.
Miért TDP/48 az egy magra eső TDP?
Miért osztod el a 36-ot kettővel?
Hogy jön a 12?

"a normál processzornál a terhelés növekedésével csökkenő a magok órajele, itt meg elképzelhető olyan szervezés, hogy 4-5 kicsi magot ki kell kapcsolni ahhoz, hogy egy nagyot be lehessen kapcsolni"

Nem értem, hogy miért kéne kikapcsolni? Ha a nagy mag átveszi a terhelést egy kismagról, ami terheletelnné válik, akkor azt persze akár ki is lehet kapcsolni.
Ha az a 4-5 kicsi mag terhelve van, akkor ezt le tudja játszani úgy a processzor, hogy akkor egyik mag sem turbózik.
Én nem látom itt sem a különbséget az 5950X-hez képest. Ott sem történik meg az, hogy "bocs, de a CCX1-en a Core1 turbózni szeretne, ezért sorry, de a CCX2-n két magot - ami egyébként dolgozott - most lekapcsolunk" Nyilván meg lehet tenni, ha nincs terhelés és nyilván meg is teszik, de amikor a CCX2 magjai is terhelés alatt állnak, akkor a CCX1 Core1 nem turbózik, és nem is ketyeghet olyan magas órajelen.

Nem értem, sajnos, hogy miért látod úgy, hogy a TDP kerettel való gazdálkodás két különböző mag-csoport között megoldhatatlan kihívás, amikor ezt megoldja az 5950X is, de ott van az AMD Smartshift, ami fizikailag két különböző helyen levő CPU és GPU közötti közös TDP keret gazdálkodást oldja meg.

Az tény, hogy az egész azon áll vagy bukik, hogy a Windows 11 ütemezője jól kezeli-e az egyes magok képességeit és a szálak igényeit. Az ezzel kapcsolatos félelmet értem, ha ez nem jól működik, az egész koncepció kuka.

Azt a kritikát is értem, hogy amikor az AMD elszabadította a magszámot, akkor a szoftverlicensz-ek mind átváltottak socket-ról magszámra. Ebből a szempontból nyilván hátrányos a kis mag, mégha egyébként tranzisztor- és energiahatékonyság szempontjából előnyös is MT workloadra. Ha valami, akkor inkább ez szól az ellen, hogy a heterogén magokat bevessék szervek terén.

Találgatunk, aztán majd úgyis kiderül..

"Az tény, hogy az egész azon áll vagy bukik, hogy a Windows 11 ütemezője jól kezeli-e az egyes magok képességeit és a szálak igényeit. "

Az a baj, hogy én még elvi szinten sem látom, hogy mi alapján tudna dönteni a windows. Mivel amikor egy program egy szálat indít mindig tök véletlenszerű, hogy milyen azonosítót kap az adott szál, mivel eddig ez egyáltalán nem számít jelenleg. Ha viszont mindig véletlenszerű, hogy az adott szálon milyen feladat fut, nem is lehet előre megmondani, hogy erős vagy gyenge mag kell neki. Utólag elemezni és átpakolni tök fölösleges szerintem, mivel ez is csak lassítana. És ha már elemzés akkor is mi alapján? Egyáltalán nem biztos, hogy egy 100%-on futó szálnak pl kell az erős mag.

Intel Thread director

Találgatunk, aztán majd úgyis kiderül..

van igazság abban amit írsz de azért felhasználói oldalról ez is a hozzánemértés bizonyítványa.

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