Az efficiency core-ok mire jók?

CPU-k, Cooler-ek

Próbáltam rákeresni arra, hogy miért vezette be az Intel ezt az ARM-os big.LITTLE rendszerhez hasonló arhitektúrát, de csak a marketinges rizsát találtam.
Hogy mobiltelefonban ennek a rendszernek van értelme, azt elhiszem. Hogy laptopban is van-e értelme, azt nem tudom eldönteni. De, hogy desktop gépekben ezt minek kell erőltetni, azt nem tudom elképzelni.

Szóval ha vki tudna ajánlani vmi szakirodalmat, ami hihető magyarázatot ad, azt megköszönném. Saját méréseim azt mutatják, hogy 10 E-mag kb. 2 P-maggal ér föl, és nem nagyon értem, hogy desktop prociba miért éri meg inkább 10 E-magot tenni, mint 2 P-magot.

  • 2765 megtekintés

( carlcolt | 2025. 11. 02., v – 15:27 )

"CISC" a RISC-en.

Ironikusan leginkabb x64/x86 emulaciora. :)

...ARM-on / Apple Siliconon legalabbis.

Inteleknel valoszinuleg marketing bullshit.

(Edit: kesobb olvastam el rendesen, hogy Intel volt a kerdes)

( st3v3 v | 2025. 11. 02., v – 15:57 )

"Nagyobb szám jobb" marketing.

Persze mondhatod, hogy amennyiben az os annyira intelligens üresjárati fogyasztás még jobb lehetne.

"Nagyobb szám jobb" marketing.

Máshol is ezt írják félig-meddig viccesen. De ennél jobb magyarázatot eddig nem találtam.

Az üresjárási fogyasztásos magyarázatot pedig nem hiszem el. Egy asztali gépben a DRAM, az NVMe, a táp standby fogyasztása is nagyobb, mint amennyit a procin tudnak spórolni. Laptopnál talán van ennek értelme, de desktop-nál biztos nincs.

( x-daemon | 2025. 11. 02., v – 16:13 )

van olyan benchmark, ahol a tobb maggal nagyobb pontszamot lehet elerni.

neked aztan fura humorod van...

( vasla_ | 2025. 11. 02., v – 17:52 )

Energiamegtakarítás, zöld mosoly az arcon. Desktopon ennyi az értelme, de aszatli gépet inkább vertikálisan skáláznak, több mag, magonként nagyobb teljesitmény. Ilyen háttérfolyamatokhoz jó, frissités, virusirtás. Lassab az E mag de még így is energiatakarékosabb.  Nincs is csak E magos, csak  hibrid E+P asztali.
Xeonoknál más a helyzet. Futtatsz mondjuk kubernetesben 10 podot, de valamiért kell a teljesitmény és még elinditasz ugyanabból  a podból 25 -öt, majd még 30 -at . Itt  horizontálisan skálázhatsz , van 144 magod, mind E mag, P mag nincs.

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+6780E&id=6907
Duálnál ez már 288 mag, vagyis jól skálázható podokhoz, konténerekhez. 


Hagyományos szervereknél, téglagyár hagyományos  ERP rendszeréhez szintén nen érdemes az E magos xeon. 

https://blog.claryel.hu

( Raynes v | 2025. 11. 02., v – 17:54 )

Nincs ilyen ökölszabály, hogy 10 kismag 2 nagymagnak felel meg. Architektúra és generáció függvénye. A valóságban tényleg működik, sok kismag tényleg felér a nagy magokkal teljesítménnyel benchmarkokban, és jól tartja magát egy több nagymagos procihoz képest is. Pl. egy N100, N150, N300, újabb Core3 (néhai i3 átnevezve) procikban sokszor csak E core van, és mégis verik a korábbi nagymagos procikat. Így szarnak nem mondanám a koncepciót, valóban működik, hoz megfelelő teljesítménynövekedést.

Ennek ellenére én se szeretem a heterogén magos procikat, OS oldaláról megbonyolítja az ütemezést, ami már enélkül is elég bonyolult a közös L3 cache-en osztozás, logikai szálazás, meg a NUMA figyelembevétele miatt. Úgy néz ki, hogy ez mégis egy trend, máshogy nem tudják már a magok számát növelni, csak ha egy magot egyszerűsítenek kismaggá.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

( mauzi v | 2025. 11. 02., v – 18:06 )

Saját méréseim azt mutatják, hogy 10 E-mag kb. 2 P-maggal ér föl, és nem nagyon értem, hogy desktop prociba miért éri meg inkább 10 E-magot tenni, mint 2 P-magot.

Totálisan nem értek a CPU architektúrális felépítéséhez, de szerintem rossz irányból közelíted meg a dolgot, amikor az E magokat összeméred a P magokkal. Másra vannak. Ha bármi olyan dolog előkerül, amihez számítási teljesítmény kell, akkor a P magok játszanak, és ne akarj 10 E maggal versenyezni 2 P maggal.

Egy tipikus modern rendszeren többszáz processz fut egyszerre, amiknek a zöme alig kér CPU-t, viszont az ütemező szempontjából az nagyon nem mindegy, hogy egy CPU magon 200 processz osztozik, vagy csak 20. Feltételezem, hogy mindenféle késleltetések egészen másképp alakulnak, és a feldolgozás parallelizációjának is sokkal jobb a több mag. Én is azt feltételezem, hogy ha csak a nettó előállítási költségről lenne szó, valószínűleg olcsóbb lenne a gyártónak is 2 P magot legyártani, mint 10 E magot, talán a felhasznált wafer mérete miatt is.

Saccra az E és P magok versenyének nincs köze a fogyasztáshoz. Ha a P mag 5-ször gyorsabb, de emiatt 1/5 annyi idő alatt végez a feladattal, akkor nem feltétlenül fog többet fogyasztani.

Inkább arra tippelek, hogy a P-mag nem 5-ször akkora felületet foglal a szilíciumon, hanem többet. Ezért olcsóbban jön ki, ha 5-ször annyi E-magot tesznek egy prociba. Ami viszont sok tekintetben lassabb lesz, mert nem minden feladatot lehet végtelenül párhuzamosítani.

De minderre nem találtam forrást, hanem csak spekulálok. A följebb említett 144 magos szerver proci is ebbe az irányba mutat.

Ha a P mag 5-ször gyorsabb, de emiatt 1/5 annyi idő alatt végez a feladattal, akkor nem feltétlenül fog többet fogyasztani.

De ha meg ugyanannyi idő alatt végez az E mag is , akkor meg 1/3-a a fogyasztása mint a P core-nak. Ha jól tudom win11 -ben van valami terheléselosztó pont emiatt, ami figyeli a terheléseket, és ha alacsony az e-re osztja a webböngészést , javascriptet, fájlbeolvasást, stb. Ezek nem cpu igényesek, most amikor irom ezt a hozzászólást 3-6% a cpu terhelés. Az e core-ok idlében nem fogyasztanak , szinte nulla a fogyasztásuk. Meg a fenntarthatóság, egyéni szinten , otthoni környezetben  nem számit , de adatközpontban bekapcsolsz egy szervert és 1 kilowattot fogyaszt majd ?  Ugyanazt a "weboldalt szolgálod ki" ugyanazzal az egy programmal ami 1 -244 példányban tud futni, egy ilyen procin. (vagy még többen ha bírja) , ha nincs full terhelés ahhoz igazodsz és  akkor kilo és megawattokat takaritanak meg.

Közben megnéztem win 11 -ben már van ilyen elosztó: Intel Thread Director.

 

https://blog.claryel.hu

( Caro | 2025. 11. 02., v – 19:47 )

Cinebench-ben jól mutat, azt meg gyakran használják a tesztelők mérőszámnak.

Az egy jól párhuzamosítható feladat, tehát ha van sok, de kicsi, keveset fogyasztó magod, akkor jobb lesz a végeredmény.

( hory v | 2025. 11. 02., v – 23:33 )

Azt tudom elkepzelni, hogy a fo applikacio futtatasahoz akkor context switch nelkul megoldhato az osszes P mag allokalasa, az E magokon osztozhatnak a hatterbeli taskok/app-ek.

Ennek lenne ertelme, de persze kell hozza kernel scheduler support is, az meg -amennyire hallottam- erosen nem szokott jonni ilyen specialisan helyzetekre... Bar ahogy irod, az ARM miatt lehet, mar van benne.

( XMI | 2025. 11. 02., v – 23:35 )

Amit leírok, az inkább az AMD-féle Zen "c" magokra igaz, az Intel szerintem túllőtt a célon az E magokkal (legalábbis desktopra biztosan).

Ahogy egyre több magot terhelsz le, nő a fogyasztás, így az elérhető maximális órajel egyre lejjebb megy, hogy a teljes "package" fogyasztási keretbe beleférjen. Vagyis nem lineárisan skálázódik a teljesítmény (és most nem a szoftveres részére gondolok), mert az összes mag órajele megy egyre lejjebb és lejjebb. 

Egy bizonyos szint után az újabb mag leterhelésével már annyira alacsonyra le kell vinnie az órajelet az összes "nagy" magon, hogy jobban jársz egy kisebb teljesítményű maggal:
- Egyrészt a kis mag a közös fogyasztási keretből kevesebbet vesz el, tehát a már leterhelt nagy magok órajelét kevésbé csökkenti tovább. 
- Másrészt ebből a kevés fogyasztási részesedésből a kis mag azért több számítási teljesítményt hoz ki, mint amit egy nagy mag tudna ugyanennyiből.
- Harmadrészt a kis magok általában alacsonyabb maximális órajellel rendelkeznek, viszont mire sorra kerülnek az ütemezésben (az összes nagy magnak már van kiosztott feladata), addigra a nagy magok órajele is lemegy annyira, amit a kis magok tudnak. Például felesleges 16 darab magot legyártani úgy hogy mindegyik tudjon 6 GHz-et, ha a fogyasztási keretbe csak 1 mag 6 GHz-en járatása fér bele és mondjuk 8 leterhelt magnál már csak 3,5 GHz-en tudnak menni. Akkor a 9.-16. magokat bőven elég max 3,5GHz-es órajelre tervezni.

Mindez persze feltételezi, hogy a "kis" mag funkcionálisan teljesen ekvivalens a "nagy" maggal, csak a maximális órajele alacsonyabb, valamint kevesebb cache van benne. Ez nagyjából az AMD-féle megoldásra igaz, a kis "c" magok logikailag teljes értékű Zen magok, csak az alacsonyabb cél-órajel miatt kevesebb és kisebb tranzisztorokkal (igen, nagyon nagy órajel eléréséhez van olyan, hogy több tranzisztor kell ugyanannak a logikának a megvalósításához). Cserébe itt a "c" mag területre csak ~50-60%-a a nagy Zen magnak.

Az Intel egy teljesen másik fejlesztési irányból indulva (a régi Atom processzorok design-ját továbbfejlesztve) csinálta az E magokat, amik ugyan sokkal kisebbek, kb 25%-a P magnak és sokkal kevesebbet is fogyaszt, viszont utasításkészlet szempontból sincsenek egy szinten. Emiatt a P magokból is ki kellett herélni az AVX512-t, mert (surprise-surprise) az alkalmazások nem tudják lekezelni, hogy néha AVX512-t tudó magon futnak, de menetközben bármikor átütemeződhetnek AVX512-nékülire és viszont. Szóval ezért gondolom, hogy az Intel egy picit "túltolta" és óvatosabban kellett volna ezt bevezetniük.

Régóta vágyok én, az androidok mezonkincsére már!

Szép összefoglaló.

az alkalmazások nem tudják lekezelni, hogy néha AVX512-t tudó magon futnak, de menetközben bármikor átütemeződhetnek AVX512-nékülire és viszont.

Itt annyi, hogy ez az, amit a kernel scheduler-nek tudnia kellene. Az egy dolog, hogy b* -nak beletenni, de ha mást nem, core affinity-vel megoldható lenne ma is, userspace-ből.

 

A másik, a "viszont" szó nem igaz; ami elfut az E core-on is, az elfut a P-n is.

 

Ami engem legjobban meglep, az az, hogy így kb. 10 évvel a heterogén cpu core-ok megjelenése után még mindig mennyire harmatgyenge a kernel scheduler-ek és úgy generálisan a userspace ezirányú tamogatása. Hogy a legalapvetőbbet mondjam: ha én akkukímélő módba kapcsolom a laptopom, akkor miért nem csak az E core-okat használja? Meg hasonlók -- totálisan megfeledkezett az Intel arról, hogy az frankó, hogy kész a hardver, csak épp szoftver nincs, ami használja.

Ez az, hogy jelenleg nem tud ilyet. Létezik az affinity feature, amivel azt hiszem meg lehet adni, hogy egy szálat melyik processzoron kell futtatni: ezt lehetne erre használni, de nincsen megoldva, hogy valóban használva legyen.

A programok egyébként ha olyan utasításhoz érnek, amit nem tudnak futtatni, akkor kivételt dobnak, a vezérlés az OS-hez kerül. Akár azt is meg lehetne csinálni, hogy az első AVX-512 utasításra reakcióként átütemezné a szálat egy P Core-ra, és megjelölné, hogy ezt a szálat mostantól csak P core-on lehet futtatni. Lehetne (szerintem), de nincsen ilyen, hanem az Intel kiküszöbölte a problémát úgy, hogy a P core-okon is letiltotta inkább ezt az utasításkészletet, hogy egyformák legyenek. Ha jól értem, mert mélyen nem merültem el ebben a kérdésben sose.

Igaz valóban hülyen lógva maradt az a "viszont". Már nem fejtettem ki, mert így is borzasztó wall of text lett amit írtam, de az a "viszont" igazából arra akart utalni, hogy ha az alkalmazás E core-on indult és ott kérdezte le a feature flageket, akkor hiába kerül utólag át P-core-ra mégsem fogja használni az ott elérhető bővebb utasításkészletet. Ez nem annyira rossz mint a fordított eset, de "a jó az nem ilyen".

Szerintem pont emiatt a userspace-ből feltételesen támogatott, runtime detektált utasításkészlet dolog miatt olyan macerás kernelből megoldani a heterogén CPU feature szinteket. Illetve nem tudom egyáltalán elvileg lehet-e úgy hogy ne maradjon rengeteg hülye corner-case amikor a kernel legjobb szándéka ellenére sem fog jól működni. Szerintem ez olyan probléma amit nem is biztos hogy egyáltalán érdemes megoldani.

Szerintem sokkal egyszerűbb lenne olyan CPU-t gyártani aminek minden magja azonos feature level-en van. Lehet AVX512-t csinálni 2 ciklusos végrehajtással 256bit széles egységeken (az AMD egy eleinte ezt csinálta, a mobil zen5-ökben most is így van), lehet AVX256-ot 2 ciklusos 128 bites egységen stb. Lehet, hogy nem lesz gyors, de nem veszik el az ISA kompatibilitás. Meg tudná oldani az Intel is, ha a cég menedzsmentje felismerné, hogy egyszerűen nincsenek abban a helyzetben, hogy megengedhessék maguknak, hogy nem oldják meg már évek óta.

Régóta vágyok én, az androidok mezonkincsére már!

Szerintem igenis van letjogosultsaga a heterogen cpu-knak. Gondolj bele, igazabol mar most is az van: vannak gpu core-ok meg cpu core-ok. De 30 eve meg ugyanez pepitaban a cpu/fpu -val.

Az hasznos, ha vannak adott feladatra specializalt magok. Az Intelnek teljesen igaza van, hogy egyszeruen nem lesz az osszes magban avx512 szamitas gyakorlatilag soha (ha igen, vegyel workstation cpu-t). Ergo penzkidobas erre meg hasonlo niche-ekre pazarolni a tranzisztorokat.

A gond az, hogy valamiert megragadtunk a 90es evekben, es meg mindig ugy tekintunk a CPUra, mint egy egy magos gepre. A GPU, meg ugy altalaban minden mas periferia eseten teljesen normalis, hogy lekerdezzuk, mit tud, es azt/ugy hasznaljuk.

Ma mar a CPU is egy eroforras, es igenis tudni kellene, hogy akkor milyen task melyik magon jo, ha fut.

Csak itt jon be a bibi, hogy egyaltalan sok dev meg mindig a multi-threading -el sincs tisztaban, az async/await modell, a lightweight thread-ek, esetleg task/job/work alapu szemlelet / kod-tervezes meg mar vegkepp betesz neki, es fogalma sincs, mit csinal.

Pedig ezek a szoftver/coding eszkozok mar evtizede adottak. Csak adoptalva alig-alig vannak.

PS: aprosag, de pl. konzolon is teljesen megszokott a heterogen processzor-architektura. sot, ha nem tevedek, ARM -en is mar evtizedes kulturaja van. csak PC-n ilyen nyogvenyelos minden sajnos.

 

PS2: masik aprosag, sokan nem tudjak: a mostani cpu-kban sem mindegyik core ugyanolyan. vannak 'elatkozott' core-ok, amiknek 1 ciklussal lassubb a cache/memoria elerese, meg hasonlo apro hardver-alapu stiklik; mikor sok mag akar hozzaferni ugyanahhoz az eroforrashoz, oda beraknak valamit a mernok urak, es az a megoldas nem feltetlen garantal ugyanolyan eselyeket minden magnak. Altalaban nem veszed eszre, de goglizz ra batran, ha gondolod, erdekes tema.

Jaja, pl. NUMA-aware dolgok is bejönnek, ha qrvasok magot kezdesz el használni, ahol vannak olyan magok amik teljesen egyformák AMÚGY, viszont nem tudják elérni direktben a RAM-ot, csak más mago(ko)n keresztül.

De ez mondjuk nem okoz invalid instruction exception-t, csak kicsit (nagyon) lassabb lesz a kód futása ezeken a magokon, összehasonlítva a RAM-ot direktben elérni tudó magokkal.

pont ezert szedtek ki az legujabb intel procikbol az avx512 tamogatast. nem azert, nem ne kellett volna, hanem mert az E core nem tudta...

 

Az  e -core meg direkt nem tudja, mert nagyon energiaigényes. Kör bezárult.
AVX-512-re optimalizált feladatok  (pl. AI, tudományos számítás) mennek GPU-ra.

Elöttem szépen leirta XMI , használsz egy ilyet, teljesitménykeret miatt meg cpu visszaveszi a frekvenciáját , ugyanott vagy. 

https://blog.claryel.hu

A vicces ebben meg az, hogy igazabol a GPU meg szinten nem a legeffektivebb mod ML futtatasra aka inferencing -re. Ugye azokat a magokat nem erre csinaltak alapvetoen.

Peldaul tenyleg franko az fp16-fp32 alapu modelleket futtatni, pontosak es gyorsak, csak epp az FP muveletek alapvetoen dragak, sokkal dragabbak, mint az int16/int32 alapuak.

Vannak specifikusan NPU-k, amiket direkt 1:1ben arra gyartottak, hogy modelleket futtassanak minimal eroforrasbol gyorsan. Es gyorsak is. Kurva gyorsak. De igen, integer alapuak es csak ennyit tudnak. Viszont nem 250W -ot zabalnak, mint egy nvidia GPU, hanem (hasracsapas) 40-et. Es az kurvara nem mindegy ebben a korban, amikor a DC teljesitmenyet szo szerint gigawattban merik :O

Es mi van akkor ha a workload valtozo? Pl. egy bongeszo lehet idle is (amikor szeretnenk hogy a hatterben futo JS e-core-on szuttyogjon), de amikor tenylegesen bongeszunk, akkor legyen gyors. Szoval az ilyen cpu "pineles" se tunik nyero otletnek.

Windows tud olyat, hogy app szinten beallithatjuk a GPU profilt es hogy "optimized for games". Gondolom az force-olja, hogy kizarolag p-core-ra utemezodjon.

Mikor inditasz egy thread-et, hozza lehetne rendelni egy profile-t, ami leirja, hogy kb. mire szamithat a scheduler (pl. spike vagy inkabb folyamatos terheles, milyen ISA, milyen extension-ok, mekkora IO es memoria-terheles varhato, stb...), es ezt tudna a scheduler hasznalni utana, konkretan rengeteg mikro-optimalizaciora.

Nem ordongosseg, tenyleg.

Bonusz pontokert virtual thread-eket is tamogathatna a kernel+userspace egyuttmukodesevel.

Valami hasonlóról irnak ezeknél a hibrid cpuk-nál, hogy mennyire hatékony nem tudom:

"Intel Thread Director egység fizikailag a CPU magokba van beépítve, méghozzá minden egyes maghoz külön."

ez figyeli hogy az adott magon futó szál milyen utasításokat hajt végre, és küldi a win11 ütemezőjének. 

https://blog.claryel.hu

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.

Régóta vágyok én, az androidok mezonkincsére már!

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.

 

De nem. Mert nem csak az adott utasítás támogatásáról van itt szó, hanem arról is, hogy mire lehet számítani az adott magtól egy adott workload futtatása közben. És az nem csak egy utasítástól függ, hanem nagyon sok egyébtől, pl. elvárt sebesség, fogyasztás, stb...

Hogy reductio ad absurdum kifigurázzam, amit írsz: persze, végülis szoftveres render is van, nem kell ide GPU... Vagy lehet inference-elni procin is, persze, csak türelem kell hozzá. :) Csak ugye nem ez az ötlet, és aki ilyen workload-okat futtat, annak az nem jó, kvázi inkább ne is lenne, mert így nem fogja használni.

"Hogy reductio ad absurdum kifigurázzam, amit írsz" - de ne figurázd ki, mert ez az egész probléma pont arról szól hogy valami értelmes középutat kell találni, nem pedig arról hogy fullba kell tolni valamelyik szélsőséget.

Az efficiency core mindig egy kompromisszum lesz. A kérdés, hogy csinálunk egy durva funkcionális kompromisszumot, amihez kb köré kell építeni a komplett szoftveres ökoszisztémát kernel, ABI, fordító, linker és teljes userspace számára invazív változtatásokkal. Vagy csinálunk egy enyhe teljesítménybeli kompromisszumot (itt reálisan a kis magon kb fele olyan gyors avx512-ről beszélünk - egy olyan magon, ami amúgy is eleve lassabb a P magnál), amit a kernel best effort jelleggel próbálhat optimalizálni.

Régóta vágyok én, az androidok mezonkincsére már!

Én azt nem értem, hogy eredetileg az volt a mondás, hogy az efficiency core arra kell, amikor a gép "kvázi" idle. Videót nézünk, szöveget szerkesztünk, tehát használjuk, de nem nagy teljesítménnyel. Azt gondolnám, hogy erre a célra néhány mag kell összesen. Valójában ha kvázi idle a gép, akkor arra 1db-nál nem kellene, hogy több kelljen. Már 4 is overkill. Ehhez képest beletettek az új laptopokba vagy 8-at és azzal fenyegetőznek, hogy még több lesz belőlük. Mintha elvesztették volna a fókuszt, hogy mire is kellenek ezek.

Olyan workload-hoz, ami masszivan parallelizalhato, ~0 veszteseggel, sokkal jobb ar/ertek aranyt tud a sok E mag, mint a keves P. Vagy más szóval, adott négyzetmilliméterből / tranzisztorból sokkal nagyobb teljesítményt tudnak kihozni E core-okkal, mint P-kkel.

Marpedig ahogy a developerek kezdik megtanulni a parhuzamos programozast, egyre tobb ilyen van.

Legutobb ugye az ML modellek futtatasa jott be ezugyben, de van sok masik is. Ma mar kvazi 0 veszteseg a video transcode parallelizalasa is.

Igazabol megforditanam: a sok E mag melle tesznek par P-t, hogy tudjal rajta jatszani is, meg olyan regi vagy regi-modi app-eket futtatni, ami nem tudta megoldani a massziv parhuzamos mukodest. De ilyenbol egyre kevesebb van.

Nem egészen. Mert ha a szerencsétlen scheduler nem tudja, melyik mag mire képes, akkor simán rá-schedule-öli az E magokra pl. a játék render engine kritikus részeit, aztán meg vakarja a fejét a user, hogy miért ilyen tetű lassú a vadiúj csúcsprocesszora.

Nem, sajnos a CPU core képességeinek ismeretét és schedule során való felhasználását nem lehet megspórolni. Ha valamit megtanultunk az elmúlt 10 évben, akkor az ez.

De ha meg a scheduler úgyis tudja, akkor akár ki lehetne adni a userspace-nek is, és lehetne használni értelmesen, ahelyett, hogy a scheduler megpróbál heurisztikával találgatni, hogy kinek mi kell... Ami aztán olyan is lesz.

Ez létezik amit írsz. A linux legalábbis tud olyat, hogy az adott mag maximális elérhető órajele alapján ütemez: https://www.phoronix.com/news/AMD-Preferred-Core-Better-6.14 és ennek illene kivédenie, hogy a játék legjobban terhelt threadje E-coreon ragadjon.

Tehát ha a "performance" core-ok magasabb órajelet tudnak, akkor az ütemező először azokat fogja tölteni, és ha már tele vannak, akkor kerülnek sorra a lassabbak. Ha úgy tetszik, az órajel, mint paraméter jelzi a kernelnek hogy mi legyen a preferencia. Nyilván ennek feltétele, hogy a "gyors" mag minden szempontból gyors legyen, ne pedig egyik szempontból az egyik mag, másik szempontból a másik legyen jobb (mint Ryzen x3d-nél, ahol a nagy cache alacsonyabb órajellel jár együtt).

Létezik még ez is: https://www.kernel.org/doc/html/latest/scheduler/sched-energy.html viszont ez nem működik SMT-t (aka hyperthreading) használó CPU-kon. Elvileg ez tudna dönteni power profile alapján, hogy most éppen a takarékos magok legyenek preferáltak vagy a gyorsak.

Régóta vágyok én, az androidok mezonkincsére már!

Na ez érdekes, de látod, 6.14-es kernelben van csak benne, és ott is csak a maximális órajelet nézi, holott kapásból tudok 5 másik fontos dolgot, amit nézni kellene, hogy a legprimitívebbet mondjam, a hőmérsékletet: ugye ha feltekeri max. órajelre a magot, az melegedni fog, és ha vissza kell skáláznia emiatt, akkor mégse jó ötlet arra schedule-olni... Meg hasonlók.

De még mindig nem tud pl. ISA-t figyelni és nincs meg a userspace<->kernel kommunikáció, hogy mit is vár a userspace, illetve mit tud adni a kernel.

Szóval ~10 év alatt odáig jutottak el, hogy már nézik a max. órajelet. Én ezt nem tenném ki az ablakba.

De a max órajel nem hőmérséklet függő is, és már eleve a hőmérsékletet is beszámítva jelzi a processzor az ütemezőnek az elérhető órajeleket? Lehet, hogy összezavarná az ütemezőt, bár az biztos, hogy érdemes lenne nem csak az eddigi és jelenlegi állapotot figyelni, hanem kicsit a jövőre is gondolni, hogy tovább lehessen használni a turbót, de gyanítom, nem olyan egyszerű a dolog, mint gondolod.

Erről eszembe jutott az oprendszerek 1 előadás, ahol azt mutatta a bácsi, hogy a lemezen a helyfoglalási stratégiáknál nem a "best fit" a legjobb, hanem sok esetben a "worst fit", de még a "first fit"-tel is jobban járhat az ember.

Ilyen szinten nem nézem a cpu-kat, de azt irják cikkekben, hogy minden maghoz tartozik egy hardveres "thread director"  INTEL hybrid -nél ami több mindent figyel,  linux 6 akárhánytól ,és még   a vm-ek is megkapják a Thread Director információit (magyarul telemetriát) :
Utasításmix: milyen típusú utasításokat futtat a szál (pl. integer, floating-point, AVX)
Energiaigény: mennyi energiát fogyaszt a futtatás közben.
Késleltetés / latency: mennyire érzékeny a feladat a késleltetésre
CPU mag terhelése: mennyire van kihasználva az adott mag.
Szál jellemzői: compute-intenzív, memória-intenzív, vagy inkább háttérfolyamat.


 

https://blog.claryel.hu

Meg tudná oldani az Intel is, ha a cég menedzsmentje felismerné, hogy egyszerűen nincsenek abban a helyzetben, hogy megengedhessék maguknak, hogy nem oldják meg már évek óta.

De, vannak olyan helyzetben. A menedzsment ugyanis csak azt látja, hogy így is veszik a procikat és nincsenek tömegek a székház előtt tüntetni. Amiről beszélsz, azt a legkorábban a mérnökök ismerhetnék fel, viszont azt mind tudjuk, hogy egy multicég esetében hogy működnek az ilyen alulról jövő felismerések...

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( dcsaba v | 2025. 11. 04., k – 21:46 )

Hardcore gamerek tiltják ez e magokat. Jövőre bevezeti ezek mellé a low-power magokat az intel.

Desktopra minden tájékozott vásárló AMD-t vesz.

Nova Lake (Desktop)

  • Series: Nova Lake-S desktop processors
  • Expected Launch: Late 2026
  • Technology: Built on Intel's 18A process node
  • Features:
    • Flagship models with up to 52 cores (e.g., 16 P-cores, 32 E-cores, 4 low-power cores)
    • New LGA 1954 socket
    • Upgraded Xe3 integrated GPU
    • Large L3 cache, potentially up to 144MB on top-tier models 

Akkor csak én értettem félre az "efficiency core" elnevezést. Tehát az "efficiency" nem jár együtt a kisebb fogyasztással. Ezt támasztja alá, hogy az Ultra 7 265k-ban 8 P, valamint 12 E mag van, és 250W-ot fogyaszt!
(Ehhez képest a Ryzen 9 9900x ugyan teszteken egy picit lassabb, viszont csak 120W-ot eszik, amit még vízhűtés nélkül le lehet fújni.)

Ezt igy nehez megmondani, mert a gyartok "csalnak" a TDP-kkel.

A legjobb, ha olyan teszteket nezel meg, amik adott workload-ot futtatnak tobb cpu-n, merik az alaplap altal felvett fogyasztast kozvetlenul, es kiszamitjak a speed/watt aranyszamot.

Meglepo modon amugy nagy elteresek nincsenek ebben. Egy egesz keskeny savban van kb. az osszes cpu.

Itt pl. talalsz "fps/watt" szamokat: https://tweakers.net/best-buy-guide/processors/benchmarks#stroom (bocsi, hollandul van - de eleg egyertelmu, vagy hasznald a translate-t).

Idle-ben mit mutatnak a tesztek? Elvileg ott azért kellene virítani valamint az én irodai gépem I5-ös Alder Lake-kel folyamatosan pörgő HDD-vel és SSD-vel nem eszik 50W-ot, mikor csak a böngésző megy, bár az is igaz , az 5600G se kér sokat, ha csak malmozik.

Olyanok ezek az E magok, mint a kis háromhengeres motorok a városi kisautókban. Városban ide-oda menve nem fogyasztanak, de ha pályázunk, egyrészt gyér lesz a teljesítmény, másrészt az is zabál rendesen.

Nagyon kellene valami dinamikusan átkonfigurálható felépítés, amit azért intel is belengetett már meg más gyártók is, de csak mint egy távoli álom. Már párszor felvetettem, és tudom, hogy nem egy egyszerű mód, de valami FPGA alapú "utasításgyorsítótár" nagyon jó lenne, hogy a gyakran használt kisebb szubrutinokra, akár OS vagy alkalmazás segítségével beálljon valami logikai hálózat, hogy gyorsabban végrehajtódjanak.

Mert nincs egy halom olyan megoldás a világban, amik nem optimálisak, csak rájuk állt az ipar és nehéz tőlük szabadulni :D 

Megint autós példa: 48V rendszer. 

De pl Elon Musk műszaki munkássága is abból állt, hogy beleállt olyan dolgokba, amibe az ipar nem akart és mégis jó lett az úgy. Persze attól még lehet baromság az ötletem, de a te érvelésed se feltétlen jó.

Akkor csak én értettem félre az "efficiency core" elnevezést. 
 

Nem értetted félre, ez a fogyasztásról szól. 

Ezt támasztja alá, hogy az Ultra 7 265k-ban 8 P, valamint 12 E mag van, és 250W-ot fogyaszt!
Ryzen 9 9900x ugyan teszteken egy picit lassabb, viszont csak 120W-ot eszik.

Fogadjuk el hogy az adatlapok jók, legalábbis összehasonlitásra. A 250 watt az a "max" fogyasztás (TDP up) , egyiknél a  typical tdp 120 watt másiknál  125 watt.

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+Ultra+7+265K&id=6326

https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+9900X&id=6171

 

Meglepo modon amugy nagy elteresek nincsenek ebben. Egy egesz keskeny savban van kb. az osszes cpu. -irja hory 

Igen, egy xeon v1 és v4 között a lényegi különbség leginkább az idle fogyasztásában van, régóta nincs már ez az évente duplájára nő a teljesitmény, ami miatt nőnek az a magok számának növelése.
Ez a hibrid magozás nyilván egy gamert nem érdekel, vitatható hogy asztali pc-n van e értelme. 
Intel nem hív meg az igazgatósági üléseire (el se mennék :-)   ), de szerintem ez a mizéria az ARM miatt van. Szervereknél, laptopoknál látható a különbség.  Laptopoknál már 20 watt különbség számít.


Egy  ARM szerver proci e-bayről: 128 mag
https://www.ebay.com/itm/267374247231?_skw=Ampere+Altra+Max
Ampere M128-30 ARM 128 Core 128 Thread LGA4926 Technology CPU | eBay
Ennyi pénzzel egy xeon boltba nem enged be a portás, jó tudom ezek használt árak garancia nélkül, de mutat egy nagyságrendet.
 

cpumark:
https://www.cpubenchmark.net/cpu.php?cpu=Ampere+Altra+Max&id=6915
Fogyasztására kb 200 wattot írnak. Nyilván ez se Gamer proci, szervereknél is felhő, webszolgáltatás  stb -hez.
De nem csak az innováció a  szempont, supportban, szaktudásban, tapasztalatban, szoftverekben még messze van a "hagyományos"-tól. 
 

https://blog.claryel.hu

Amit irsz, semmit se jelent.

Nezd meg a linket, ott nezik a cpu fogyasztasat es a kicsikart fps-t, ebbol szamolnak fps/watt erteket - na az tenyleg megmutatja, hogy mi a tenyleges hatasfok, legalabb 1-1 specifikus helyzetben.

Az, hogy hany MHz, hany magja van, vagy mit mond a gyarto a fogyasztasra, tokmindegy. Az egvilagon semmit se jelent.

 

Mikor azt irtam, egy keskeny savban van a cpu hatasfok, azt persze adott generacion belul ertettem. Nyilvan egy 2015-os proci rondan lemarad egy 2025-ostol. De nezd meg a linket, hasznos.

Desktopra minden tájékozott vásárló AMD-t vesz.

Tekintve, hogy a tájékozott vásárlók aránya tetszőleges piacon kb. pár százalék, ez nem oszt vagy szoroz.

A legtöbb user, gamert beleértve, megveszi a kész PC-t és jóccakát. Talán windows reinstall még éppen megy, amúgy a csavarhúzót már nem veszi a kezébe.

Akikről beszélsz, az enthousiast market, a teljes piac jó, ha 1% -a (azért tűnik nagyobbnak, mert ugye az összes cikkíró/youtuber/influencer ebbe a körbe esik, és figyelnek rájuk a laikusok is, emiatt a gyártók is, presztízs/marketing okokból)

A gyártók pedig meglepő módon nem azt nézik, amit te. Nekik fontosabb az, hogy időre szállítson, hogy bulk kedvezményeket adjon, vagy éppen az, hogy a gyártó szerverpiacon levő kereszt-szerződése kötelezi a gamer PC-kbe is Intel beépítésére. De náluk még ilyen apró hülyeségek is bejátszanak, hogy teszem azt, a montana-i összeszerelő üzemük csak akkor kap adókedvezményt, ha 50% -ban helyi alkatrészt építenek bele, és csak az Intel tud US-ben gyártott procit szállítani...

Pontosan ezért épít az igazi gamer/enthousiast saját PC-t, mert ott tényleg csak és kizárólag az ő szempontjai esnek latba.

( turul16 v | 2025. 11. 10., h – 09:39 )

Megkonyitik a dontest AMD -re valtashoz.

intel_pt szeru dolog van AMD -ben ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Fogalmam sincs, hogy van-e az AMD-nek ekvivalens megoldása. De a döntést nem könnyíti meg, már az AMD-nél is hibrid magok vannak, igaz még nincs közöttük nagy különbség, Zen v s. Zen-c mag, de már ők is rámentek erre az útra.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Csak gyartastechnologiai kulombseg van a Zen / Zen-C kozott, ami miatt a C magok kisebb max frekvencian mennek.

Mellesleg szerintem hasznosak az efficiency core-ok, mivel szerintem a vilagon letezo CPU-k tobbsege az ido tobbsegeben idle, vagy szinte idle, ugyhogy a felhasznalok tobbsege energiat sporol veluk.

Keszultek nagyon sok core-os ARM szerver CPU-k, allitolag egyes feladatokra nagyon hatekonyak voltak, de mar nem emlekszek milyenekre (mintha webservereknek??). Szerintem egy ARM core egy efficient x86 core-hoz hasonlit leginkabb, ugyhogy biztos megvan a szervereknel is a letjogosultsaga. Ha jol tudom az AWS-nel lehet ARM alapu VM-et is valasztani, kevesebb penzert.

Azt akkarod mondani 10 core kell notebookumba az idle nevu futatasara es marad a 2 busy -re ? ;-)
 
A CPU-nak van egy TDP limitje,  max temp limtje, ha eleri valamelyik-et jon a leszabalyzas.
Ha olyan core van a masinaban ami leszabalyozas  utan  tobbet szamol az jo.

C -forgatasnal  ez a heterogen architecture nem gond, de ha olyan feladatod van ahol minden magnak egyszerre keszen kell lenni
 (nagy matrix szorzas), akkor nem feltetlen idealis, figyelembe kellesz venni a core-k relative gyorsasagat a
 problema felszeletelesenel, amit lehet menet kozben is ujra kell kalibralni..

Regen azert rohogtunk az i7 -es kis notebookban, mert KB. fel percet ha ment hirdetett teljesitmenyen,
ezek cuccok lehet jobban mennek hosszu tavon, ha feladat is olyan.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( influencer | 2025. 11. 11., k – 00:26 )

Mire jó az e core?

Kevesebb helyet foglal, mint a p mag, lehet gyártásnál is kevesebb hibásodik meg, kevésbé melegedik, így a tdp alacsonyabb. Ha több szálon is tud futni a feladat, akkor jól skálázódik. Jól néz ki értékesítésnél, milyen sok mag van benne.

Én nagyon elégedett vagyok az i7-12700k teljesítményével, nekem mindenre bőven elegendő. Nem látom értelmét újabbra cserélni, pedig nem dd5, csak 2*32gb ddr4-3600 memóriával használom. Ha majd megunom, hogy lassú a gép a kevés memória miatt, akkor majd dobok még 64 gigát, van még 2 slot. 

Próbáltam, hogy kikapcsolom az e magokat, de nem lettek gyorsabbak a játékok sem a gyakorlatban, így visszakapcsoltam. Ha jön egy 1 szálon futó nagy terhelés, van annyi esze még a Windows 10nek is, hogy egy p magon futtatja 3,6ghz és 4,9ghz között.

Rendering, 7zip esetén az e magok nélkül jelentősen lassabb, mert az skálázható.

Remélem tudtam választ adni a kérdésedre valamilyen szinten.

Főleg h. kolléga biztos nem nézett rá a ddr4 árlistákra a napokban :) Óránként emelkedik a ddr4 (de már az 5 is) árak. 

Most van éppen az a pánik dram és ssd fronton, ami 2020 szeptemberében indult gpu témában. Aki most akar gépet építeni, nagyon rosszkor teszi sajnos.