kíváncsi leszek hogy fog hatni a gyorsítótár ezen változtatása a teljesítményre... eddig mindig is érzékenyek voltak a gyorsítótárak sebességére és méretére az intel architechtúrái...

Hát ez elég érdekes döntés.

Azt egyébként még mindig nem értem, hogy aki játék mellett stremelni is akar, az minek akarna +8 gyenge magot, amikor elérhető már most is a 16 erős mag desktopon.
Gondolom olcsóbb nem nagyon lesz, meg aztán ezen a szinten már nem igazán az a pár ezer forint szokott számítani.

[ Szerkesztve ]

inkább az, hogy a 4 kis mag-os claster akkora helyet foglal mint 1 nagy mag

Nem kell ez a kis-magos baromkodás. Vegyenek még inkább vissza az órajelből, vagy kapcsolják le teljesen a magokat, ha nem kellenek. Most előrehaladás helyett tákolás megy. A processzor olcsóbb nem lesz, milliószámra pazaroltak el így tranzisztorokat, azért hogy üresjárati fogyasztásban megspóroljanak 3W-ot. "Csodálatos" Nekem is egészen biztosan az lenne az első dolgom, hogy az összes kis nyomorék magot kikapcsolnám a p...ba.

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

Információink szerint ennek az oka az, hogy az Intel mindenképpen a hibrid dizájnt szeretné erőltetni, így nem akarják, hogy a felhasználók az Alder Lake processzorra épülő gép megvásárlása után azzal kezdjék az első röpke túrájukat a BIOS-ban, hogy az AVX-512 aktiválása érdekében kikapcsolják az E-core-okat.

és azt miért nem tudták megoldani, hogy avx512 azon fusson, amelyik mag támogatja, anélkül, hogy a kicsiket ki kellene kapcsolni?

Az intel szerintem ezzel a fajta megoldással /nem a big-littlere gondolok, hanem a herélt kokányolásra/ tökön lövi magát. Rossz úton haladnak. Ugyanakkor egyetértek Duck663-al is. Nem biztos, hogy ezt a koncepciót desktop-játékos vonalon erőltetni kéne. Az hogy jővőben ez hogy alakul, persze még kérdéses.

"Nem kérdőjeleztem meg, hogy hülyeséget mondasz!"

Lehet, az a "sok " AVX512 ismerő program megzavarodik, ha menet közben nem tudja eldönteni, hogy milyen magra is száműzte őket az OS. Attól még, hogy lassabb a mag szerintem a BigLittle esetén az az örvendetes, ha ugyanazt az utasításkészletet ismeri,mint a nagyok, csak max nem olyan gyorsan hajtja végre (legalább is egyes utasításokat), de annyira mélyen én sem ismerem ennek a működését.

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

ha valaki mélyebben benne van android bit.Little témában leírhatná mennyire működik azon a platformon. lehetne következtetni mit várhatunk. de ahol a dual/multi core támogatás is nehezen indult be itt sem vennék csak emiatt ezzel kísérletezgető 1st gen x86-ot.

An open mind is like a fortress with its gates unbarred and unguarded.

Jó lesz ez a design... Öröm lesz nézni, hogy alázza majd végig a tesztekben az AMD. :)
Úgy látszik, hogy az Intel tudatosan töketlenkedik tovább...

Quake 3 forever!

Huhh, készülhetünk az öngyilkossági hullámra. Anno, mikor AMD elkezdte püfölni az Intelt, az egyik fő érvük az volt a kék bögréseknek Intel mellett, hogy AVX-512 nélkül nem lehet élni. És mi lesz azzal a sok fizetett honlappal, ahol egész oldalakat rászánva bizonyítják, hogy az Intel előnye behozhatatlan az 512-ben? Áhhh...

Aki azt mondja "nem tudom elhinni az igazságot" az naiv. Aki azt mondja "nem akarom tudni az igazságot" az ostoba. Aki azt mondja "az igazság tilos" az gonosz. Aki azt mondja "én határozom meg az igazságot" az beteg.

Mivel telefonok esetén az üzemidő 90%-ában az ember zsebében dolgozik a proci, ott tök logikus, hogy erre az időre a nagy magok lekapcsolnak és a kicsik végzik a készenléti módhoz szükséges folyamatok futtatását, hiszen nem számít a sebesség csak az üzemidő.
Ellenben se notebookban se desktopon nem létezik ez az üzemmód. Ha nem használod a laptopot lecsukod és nem fut semmi.

Én ezt kb ugyanolyan erőltetett dolognak látom, mint amikor a microsoft kitalálta a win 8-nál, hogy akkor most mindenki használjon érintőképernyőt pc-n, mert az annyira bevált telefonon. Na ja.

Hát, izgi. A bazi hosszú utasítás pipe is. Mintha a P4-es korszakban ez egyszer már nem jött volna be.

A Little-Big meg ugye az ARM-féle magokkal jól muzsikál, mert RISC lévén kb. ugyanazt kell tudnia mindenkinek. A CISC magoknál viszont a P-knek mindent is tudniuk kellene, az E-ből meg minél többet ki kellene spórolni. Némi ellentmondás.

A tej élet, erő, egészség.

Igen, én is úgy érzem, hogy ez nem felhasználói oldalról érkező igény, hanem majd az Intel megmondja a usernek, hogy mi kell neki. Előbb-utóbb nem kapsz majd mást, főleg, ha az AMD is elkezdi ezt a hülyeséget.

Most komolyan, desktopra minek kell ilyen kifejezetten mobil irányú fejleszést hozni?, ami csak megbonyolítja mindenki életét (Microsoft némán bólogat). Desktopra, hangsúlyozom.

#tarcsad

Az intel koncepciója a big.LITTLE tekintetében nem "Efficiency + Low Power", hanem "Performance + Efficiency"
A kis magok célja nem az alacsony fogyasztás, amikor nem vagy alig használod a készüléket, hanem az energia- és tranzisztorhatékonyság, amikor igen.

A Performance magok csak a magas IPC miatt kellenek. Arra nem fogják kímélni a tranzisztort és az energiát.
Ha Multithreadre képes alkalmazástokat használsz, akkor viszont láthatod, hogy a jelenlegi magok se nagyon mennek 3.5-4Ghz fölé, mert afölött már túlságosan sokat fogyaszt 1 mag.

A cél az, hogy egy 4 szálra skálázódni képes alkalmazás ugyanabból az energiából és transzisztorból 2x akkora throughputot érjen el 4 kis magon futva, mint 1 nagy magon.

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

Szerintem meg "kazán" effektus miat lövik le... mivel ami progi ezt használja az a prescott üzemi hőfokán mozog

Egy Gyűrű mind fölött, Egy Gyűrű kegyetlen, Egy a sötétbe zár, bilincs az Egyetlen...

> android bit.Little
> témában leírhatná mennyire működik azon a platformon.

https://en.wikipedia.org/wiki/DynamIQ
The problem that big.LITTLE solves
For a given library of CMOS logic, active power increases as the logic switches more per second, while leakage increases with the number of transistors. So, CPUs designed to run fast are different from CPUs designed to save power. When a very fast out-of-order CPU is idling at very low speeds, a CPU with much less leakage (fewer transistors) could do the same work. For example, it might use a smaller (fewer transistors) memory cache, or a simpler microarchitecture such as a pipeline. big.LITTLE is a way to optimize for both cases: Power and speed, in the same system.
In practice, a big.LITTLE system can be surprisingly inflexible. One issue is the number and types of power and clock domains that the IC provides. These may not match the standard power management features offered by an operating system. Another is that the CPUs no longer have equivalent abilities, and matching the right software task to the right CPU becomes more difficult. Most of these problems are being solved by making the electronics and software more flexible.
"""

Apple M1 ( ARM ) -et érdemesebb megnézni -
most az a top big-little Desktop - lecsiszolt megoldás.

Amúgy az új ARM-es procikból
már van 3-egybecsomagolt architektúra is
( Tri-Cluster Architecture )
pl Snapdragon 888 - 8 vegyes core:
1x Cortex-X1 @ 2.84GHz 1x1024KB pL2
3x Cortex-A78 @ 2.42GHz 3x512KB pL2
4x Cortex-A55 @ 1.80GHz 4x128KB pL2

persze itt konnyebb, mert X86-on az AVX-512 eléggé nem tranzisztobarát utasítás.
Az ARM-es megfelelőjét jobban tervezték
és az SVE sokkal jobban skálázódik - fel és le is ..
Emiatt az ARM-es Vektor utasításoknak jobban fekszik a big-Little.

Mottó: "A verseny jó!"

De mivel most a 6-8 erős magos procik korát éljük, programokból meg nem nagyon tobzódunk a 8 szálnál többre skálázódok között nem nagyon értem, mi értelme a kicsi magoknak jelenleg. Ha az átlag szoftverek 50-100 szálat használnának egyszerre akkor érteném, hogy érdemes lenne bepaszírozni kicsi magokat a nagyok kárára, mert így nagyobb lenne a nyereség, de most nem ez a helyzet.

Nekem is sokkal inkább az az érzésem, hogy a gyártástechnológia hiányosságai miatt nem képesek tartani a lépést magok számában ezért most kitaláltak hozzá valami ideológiát, hogy miért is lesz ez jó.

[ Szerkesztve ]

Ma ez Performance + Efficiency-nek van nevezve, mert méret alapján 4:1 az arányuk.

Pár generáció múlva szerintem Single thread + Throughput-ként lesz felfogva.
Az utóbbi magában foglalja az energiahatékonyságot is, de dinnyényi magot raknának majd bele, és egy render pl. inkább a gyenge magokon futna.
El tudom képzelni hogy később akár 2:1 vagy 1:1 arányban osztják fel a lapkaméretet a két típus között.

Képzavarral élve, a Core magok mellé idővel csomagolnak irdatlan mennyiségű FX-et is, az utóbbiak egyre hangsúlyosabbá válva.

[ Szerkesztve ]

640 KB mindenre elég. - Steve Jobs

> nem nagyon értem, mi értelme a kicsi magoknak jelenleg.

- ha később lesz értelme,
akkor már most el kell kezdeni a szoftveres integrációt
és nem akkor amikor már késő.

- tartani kell a lépést az Apple M1 -el ..
- Környezetvédelem ; Energiahatékonyság
( már ha aggaszt téged a Globális Klimaváltozás )
Főleg ha a procikat is elkezdik - a hütőgépekhez hasonlóan osztályozni.

- Notebook-ok ; NUC-ok
következő generációs konzolok;
NAS -ok;

> Nekem is sokkal inkább az az érzésem, hogy a gyártástechnológia
> hiányosságai miatt nem képesek tartani a lépést magok számában
> ezért most kitaláltak hozzá valami ideológiát, hogy miért is lesz ez jó.

ettől függetlenül hasznos dolog.
Ha az Intel nem lépi meg, akkor tovább folytatódik az ARM - általi kiszorítás.
És az Apple-t már elvesztette.

Szóval kényszerített lépés

Az Apple - a legjobb gyártástechnológiával - a legjobb mérnökökkel - mégis ezt választotta. Főleg azért mert ezt a procit alkalmazza az erősebb mobiltelefonokban, a tabletekben és a laptopokban és az apple mini-ben is.
Ezt jelenleg az Intel procikkal nem lehet megtenni.

És ha az Intel nem lép,
az X86 elveszti a tablet és a notebook piacot is
- mint a mobiltelefon piacot.

Mottó: "A verseny jó!"

Pont ezen filóztam a cikk olvasása közben én is, hogy mennyivel egyszerűbb lenne a nagy magok órajelét, vagy magukat magokat stb lekapcsolni, mint berakni külön kis magokat, amik helyet is meg tranzisztort is fogyasztanak, árat is emelnek, aztán 10 évig kell a kismagokat futtatni majd, hogy a "spórolás" megtérüljön, a sok kismag többletgyártási költsége miatt.

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

Én azon fogok röhögni, mikor majd gyök kettő FPS-el fog futni egy rakás játék (esetleg nem is minden esetben csak néha), mert az OS nem tudja eldönteni, hogy melyik magra is kellene rakni. Aztán majd jöhetnek a patchek a Windowsba meg a játékokhoz is...

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

Szerintem mert alapjaiban egységesíteni akarnak. valami hasonló volt az a baromság is a Win8nál, hogy induljunk ki abból mindenki érintőkijelzőt használ.

Elég lenne ha a nagy magok/szálak terhelés függvényében fel-le kapcsolódnának meg váltanák az órajeleiket... jah hisz ezt már a mai CPUk is tudják XD (legalábbis az órajel váltást mindenképp)

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

Az 8 magos zen megjelenése előtt ugyanezt a kérdést fel lehetett tenni - és fel is tették: mégis mi értelme lenne 6-8 magos procit venni, 4 mag (i5) mindenre IS elég, aki egy kicsit flancolni akar az meg megveszi a 8 szálas i7-et.
Eltelt pár év és eléggé standarddé vált a 6/12 konfiguráció, ennél gyengébbet csak az vesz, aki kifejezetten spórolni akar, vagy amd esetén apu-t.

Természetesen nem állítom, hogy minden program hatalmas lépéseket tett abba az irányba, hogy több szálon skálázódjon. a DX12 és a Vulkan megjelenésével leginkább a játékokon lehet ezt tetten érni. De tegyük hozzá, hogy ha megnyitod a rendszerfigyelőt, azt láthatod, hogy a chrome is kismillió szálon fut. Ezek nem terhelnek nagyon, de annyira biztosan, hogy lehessen rajta energiát spórolni azzal, hogy egy kisebb mag szolgálja ki.

Ezen a ponton látszólag kicsit ellent fogok mondani magamnak. Mindenesetre a "mi ételme a kis magoknak?" kérdésre a válasz az, hogy az Alder Lake elsősorban mobil fejlesztés. (Ahogy ez mindig is volt az intel asztali processzorai esetében)
Tehát az lesz a 8 kis mag értelme, hogy amikor meg van nyitva a notebookon 10-20 chrome tab, akkor azokat elviszik a kis magok is.

Amiben viszont szerintem különbözni fog az Intel megközelítése az Apple-től, hogy jelenlegi ismereteink szerint a throughputot az Apple nagy magokkal, míg elképzelésünk szerint az intel a kis magokkal fogja megoldani.
(Ahogy azt tanult kollégám paprobert #20 is mondta)

8 kis magtól nyilván nem várható átütő erő throughput vonatkozásában. A későbbiekben fog ez a szám emelkedni. A raptor lake-ben 16, később talán már 32 lesz. (a 8 nagy mag mellett persze)
32 kis mag, ami rendelkezik 16 nagy mag teljesítményével, de elfér 8 nagy mag helyén és beéri 8 nagy mag fogyasztásával.*

(* a tényleges teljesítményadatokkal majd várjuk meg a teszteket)

És hogy ez hová lesz majd jó?
Mondjuk egy 8+16-os konfog bárhová jó, ahová jelenleg az AMD 16 maggal lő. Én nem tudom kik azok pontosan és milyen felhasználási területen van szükség 16/32 processzora, de az biztos, hogy az intel ezt a kihívást throughput szempontjából 16 nagy magnyi lapkaterület lés fogyasztás helyett csak 12 nagy magnyi lapkaterületből és fogyasztásból fogja kivitelezni.

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

ami van eroforras fel lesz hasznalva.
egyebkent meg kar az 8086ot toldozni foldozni.
ujra kene irni az egeszet, kulonben lenyomja az arm maholnap mint az apple.
egyszeruen egysegnyi silicon felhasznalasban a jelenlegi x86 nem annyira hatekony.
legalabbis ha joltevedek.

Órajelet váltani nem ugyan az mint menet közben magot (főleg ha úgy van mint az intelnél hogy nem egyezik a két mag működése) nem lehet csak így ide oda dobálni a dolgokat

Egy CISC soha nem lesz olyan hatékony, mint egy RISC. Egyszerűen azért, mert az előbbi tele van ritkábban használt utasításokkal, amik mind foglalják a szilíciumot, és fogyasztják az áramot.

De ne feledjük, régebben a komolyabb számítógépek RISC-ek voltak, innen haltak ki, és nyert teret helyettük a CISC. A jelenlegi ARM-erősödés is elsősorban a mobil eszközök irányából jön, ahol nagyon számít a fogyasztás.

A tej élet, erő, egészség.

nem is kell pontosan olyan hatekonynak lennie. de jelenleg teljesen sok szilicium megy el a visszafele kompatibilitas megorzese miatt.

[ Szerkesztve ]

Mire gondolsz? Az x86-os utasításokra? Amik pont lehetővé teszik, hogy az alkalmazások nagy része (a 32 bitesek) még mindig elfusson rajta?
De a CISC-nek épp az a problémája, hogy mindenkinek más a felesleges belőle. Más egy böngészőnek, más egy játéknak, más egy adatbázis-kezelőnek, más egy webszervernek, más egy régi programnak. De ezek közül mindegyikre akar optimális utasításokat tartalmazni. Ahogy több képfeldolgozás kellett, jött a SIMD. Ahogy több titkosítás kellett, jöttek az ezt támogató kiterjesztések. Most a neurális hálók tanítása a buzzword, hát ezt támogató mátrixműveleteket tömnek bele (még ha a GPU-kban már amúgy is adott hozzá sok minden).

A tej élet, erő, egészség.

pl 32 bit kivagasa. jaja.

Fenéket, ez nem ilyen egyszerű.
Van művelet ahol a CISC teljesít jobban, és van ahol a RISC. Egyébiránt a modern x86/AMD64 procikat egyszerre drótozzák RISC és CISC futtatásához, csak a CISC dominál. Kb. mintha azt mondanád, a C++ sosem lesz olyan gyors mint egy gépi kód. És akkor mi van? Ha ezzel érvelsz, nem érted a lényeget.
Itt egy viszonylag friss cikk a témában, a címe beszédes.
[RISC vs. CISC Is the Wrong Lens for Comparing Modern x86, ARM CPUs]

Aki azt mondja "nem tudom elhinni az igazságot" az naiv. Aki azt mondja "nem akarom tudni az igazságot" az ostoba. Aki azt mondja "az igazság tilos" az gonosz. Aki azt mondja "én határozom meg az igazságot" az beteg.

Érdemes elolvasni/meghallgatni Jim Keller legutóbbi témában adott interjúját.
Szerinte az ISA önmagában kevésbé számít.
[link] [link]

Minél régebbi egy ISA, persze annál terheltebb lehet saját múltjával való kompatibilitással.

Ma legalább annyira fenyegeti az x86-ot az arm, amennyire az armot a RISC-V.

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

Pont ezért nem értem, miért nem inkább (tovább) órajelcsökkentéssel próbálkoznak.

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

az anandos interjujat mar lattam.
amikor a szazalekokert is kemenyen meg kell izzadni, akkor szvsz ki kene dobni.

igen ez egy korforgas. osszes arch igy indul h szar a mostani aztan addig bovitik amig masok mondjak ra h szar.

Az AVX512-őt nem sajnálom, ellenben az Intel hatalmas bokán lövést végez ezekkel az E-core magok erőltetésével. Egyrészt a desktop közösség többsége azzal kezdi majd hogy kikapcsolja, másrészt amennyit az drágít, lehet megüti a vásárlók ingerküszöbét. Amúgy valami olyasmit vélek, hogy itt most az a koncepció, hogy az asztali és notebook vonalat össze akarják boronálni, merthogy utóbbiban a heterogén koncepciónak még lehet értelme. De kb. az lesz, mint a win8 idején az MS agymenése, hogy csempét mindenhová.
Amúgy egy dolog még lehet a háttérben! Az mindenki által köztudott, hogy avx512 alatt elég brutálisan megemelkedik a cpu étvágya. El tudom képzelni, hogy a tpd keret fenntartásának érdekében áldozzák be. Akárhogy is, a 8+8 helyett lehetett volna 10 nagy mag, az piacképesebb lenne, mert nagyon kell a teljesítmény, minthogy az Amd ellen valami erős procit kell villantani, mert ők sem ülnek a babérjaikon.

izé

Kb. semmi. Az x86 nem feltétlenül 32 bites. Mivel rész-egész kapcsolat áll fenn, ezért nem eltávolítható. Nincs mit kivágni. A mai CISC processzorok valójában hibrid architektúrára épülnek (pl. futószalagok). Nem lehet különválasztani a két típust. Hiába azonosak az elvek, a mikroarchitektúra már régen más alatta. Ebből következik, hogy két x86-os processzor belső felépítése teljesen eltérhet egymástól. Nem ez határozza meg a végső teljesítményt. A 64 bit stb. sem jelent különösebb előnyt sebességben. Összetettebb utasításkészlet segítségével hatékonyabb kódot lehet írni speciális esetekre, ezért gyorsabb lehet. Az optimalizáció számít, a többi kevésbé.

Müzli 38% gyümölccsel: "Száraz, hűvös helyen tárolandó. Az elemzés értékeit a természetes termékek biológiai variáció. Hiszen ebben a gabonafélék természetes termék tartalmazhat nukleáris alkatrészek, részek és kő shell alkatrészek is." De legalább természetes.

Mert sokkal gyorsabb clustert valtani. De ezt irta is pelgrim.

2024: nem lesz kegyelem a HMD-féle hulladékgyáraknak.

Senkit nem érdekel a desktop, a piac elenyésző darabját jelenti. Van laptop (ahol ez a stratégia valszeg beválik), meg van workstation/server (ahova a Sapphire Rapids megy). Desktopra nem lesz új fejlesztés, majd kap valami leszármazottat a két vonal egyikéből.

A sok kis mag - valószínüleg a jobb hüthetőség miatt - nagyobb multi teljesítményt tud leadni.

Mottó: "A verseny jó!"

Már olvastam ezt a cikket korábban. Mi több, a berakott grafikon is onnan van.

Arról is tudok, hogy a CISC-ek is belül elemi uOP-okra bontják az utasításokat, tehát egy komplex címszámításos memóriaolvasó utasításból lesz több, kvázi RISC-szintű művelet, amit aztán a belső futószalagok jobban össze tudnak egymással pakolni. De ez mégsem RISC; szó sincs arról, hogy az AMD64 procikat RISC futtatásához is drótoznák.

Mindez nem változtat azon, hogy felhasználási körtől függően a CISC szilícium egy része kihasználatlanul marad, miközben persze más funkciói meg így is szűkösek. (Pl. kódolásnál csak az egész számos vektoregységek pörögnek, matematikai számításoknál meg csak a lebegőpontos aritmetika van kihajtva).

A tej élet, erő, egészség.

azert utasitaskeszletek vannak am, pl 3dnow. amit ki is hajitottak. illetve az intel is kitudja miert tiltotta le inkabb az avx512t.

az itanium elverte nagyon sok helyen az x86ot hatekonysagban. a compileren bukott el gyakorlatilag.

[ Szerkesztve ]

Az Itaniumnál mai napig nem tudom, hogy végül is a NyAu-s matematikusok voltak balf@szok vagy az intel, hogy ilyet tervezett még készen nem lévő optimális fordító nélkül? Tehát volt-e egyáltalán elvi lehetőség arra, hogy tetszőleges C kódot úgy fordítsanak, hogy a többi architektúrához képest jelentős előnye legyen, és legrosszabb esetben is hasonló hatékonysággal fusson?
Esetleg, ha ma vezetné be és nem lett volna ennyire lejáratva a marketingje, jobban működhetne ez az elv?

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

az itanic vliw, a sorrendet szoftver donti el nem hw
kis tulzassal ezen bukott el.
qrvanehez jo compilert irni ilyen szinten, foleg altalanos celu vasra.

a lejaratast az intel koszonje maganak. o hazudta igerte h emulalva is gyorsabb lesz az x86 mint vason.

Ok, de volt erre elvi lehetőség? Volt legalább egy matematikus, aki nem pénzért, hanem tudományos alapokon azt mondta, hogy megoldható?

Le az elipszilonos jével, éljen a "j" !!!

Lehet, hogy lesz akár 16 vagy 32 kicsi mag is, de egyszer ez már elbukott a xeon phi-nél. Ott is volt baromi sok kicsi x86-os mag de valami miatt nagyon nem hozta azt amire számítottak. Persze nem látok bele, hogy ez most mitől más, de azért elgondolkodtató.

Hány olyan PC-s alkalmazásról tudunk (ami nem benchmark) ami számottevően gyorsabban működik AVX-512-t támogató CPU mellett?

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Én speciel egyről se.

Szerintem megint egy elég távoli helyről hozol példát.
A Xeon Phi célja x86 alapon egy olyan gyorsító megvalósítása volt, amilyen célra máskülönben mondjuk inkább GPU-kat használnak.

Ahogy korábban is mondtam, 16, meg 32 Efficiency mag azokon a felhasználási területeken lesz hasznos, ahová, amire ma a 16 magos Ryzen-t vagy 16-64 magos Threadrippert veszik jelenleg. a 64 magos Threadripperre is azt mondanád, hogy hülyeség az, mert a bulldozer, meg Xeon Phi is megbukott?

Összehasonlításképp:
A Gracemont-tól a Golden Cove mag csak 33%-kal magasabb IPC-vel rendelkezik.
A 64 magos TR esetén se mennek a magok 2.9Ghz-nél többet teljes terhelés esetén.

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