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.
- 1733 megtekintés
Hozzászólások
"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)
- A hozzászóláshoz be kell jelentkezni
"Nagyobb szám jobb" marketing.
Persze mondhatod, hogy amennyiben az os annyira intelligens üresjárati fogyasztás még jobb lehetne.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Nézd meg azért legújabb CPU-k max fogyasztását..
Ráadásul a sötétzöld ideológia szemüvegén keresztül kell értékelni..
- A hozzászóláshoz be kell jelentkezni
van olyan benchmark, ahol a tobb maggal nagyobb pontszamot lehet elerni.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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á.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ezt egyébként hogyan csinálja? Van egy alkalmazás amely több szálú. Az egyik szálban használok olyan utasítást amit nem minden core támogat. Honnan tudja a scheduler, hogy akkor most ezt a szálat az X típusú core-on nem szabad futtatni?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
pont ezert szedtek ki az legujabb intel procikbol az avx512 tamogatast. nem azert, nem ne kellett volna, hanem mert az E core nem tudta...
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ma mar a CPU is egy eroforras, es igenis tudni kellene, hogy akkor milyen task melyik magon jo, ha fut.
De honnan tudna ezt egy scheduler elore?
- A hozzászóláshoz be kell jelentkezni
Mondjuk el neki?
Hogy a 27 eves ELF nem tamogatja, az meg oke. Azonban, hogy az alig 1 honapos 4.2 sem (tenlyeg nem?), az mar eleg erdekes.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Desktopon. Mobilon 2 éve (Meteor Lake - Core Ultra Series 1 óta) van ilyen.
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Tudtommal az FPGA-k orajele messze elmarad a CPU-ektol. Tehat hiaba toltenenk be egyedi logikat ra, ha csak max 1GHz-et ketyeg, mig mellette 5GHz-en a P core.
Ha ez ennyire nyilvanvalo otlet lenne, akkor mar reg elterjedt volna.
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni