Vlákno názorů k článku AMD oficiálně potvrdilo big.LITTLE procesory a APU Phoenix2 se Zenem 4c. Měří 137 mm² od Sing - "AMD přímo nepotvrdilo ... že Phoenix2 bude v...
-
Najednou bigLittle není fůj protože to má i AMD, zajímavé :D Až AMD začne dělat ARM procáky tak předpokládám že už taky nebudou fuj :D
Sranda je, že x86 jen kopírují ARM se zpožděním 12 let. První big.Little byl Cortex A7 / A15 někde v roce 2011. Mají trošku delší vedení, no co už :D
Revoluční SVE vektory jejichž instrukce jsou nezávislé na délce vektoru (až 2048-bit) má ARM od 2016 a všechny mobily a servery to už mají ve druhé generaci SVE2 poslední 3 roky (od jádra X2 což bylo první s ARMv9+SVE2, a taky to bylo 64-bit only, všechny 32-bit historické sračky zahodili). Po 7 letech u x86 pořád ticho po pěšině, signál pořád putuje po vední a ještě těch 5 let putovat bude :D
A co takhle pořádnej RISC desktop se 128-jádry 64-bit ARMv8 co vydrtí i Epycy?
A běží na tom Crysis i W10. A má to 6-kanál paměťovej řadič, ne jak ty předražené Ryzeny s trapným 2-kanálem :D
https://youtu.be/ydGdHjIncbk5. 7. 2023, 10:26 editováno autorem komentáře
-
Na tohoto spambota jehož model běží na ARMu nemá smysl reagovat. Ale zkusím to.
1)Kriplcore je fuj i když je od AMD. Však ho AMD bude dávat do těch nejlevnějších CPU.
2) AMD ho kriplí jen frekvencí. (Na rozdíl od intelu který nemá AVX512 a HT) Pak ještě L3 cache, ale to záleží jak se to bere. Jestli celková kapacita (zůstává stejná) nebo velikost na jádro. (Která se zmenšuje protože počet jader roste.)
(intel řeže L3 levným CPU v rámci segmentace i když by nemusel.)
3)Až AMD bude dělat ARM tak to bude taky fuj.
4)big.LITTLE je dobrý pro mobilní telefony. Ty AMD nedělá. LITTLE je dobrý pro cloud servery.
ARM tam neuspěl. AMD do cloud trhu naskočila letos. A válcuje konkurenci o parník. 4c jsou tak dobrá, že se to vyplatí i v NTB. Třeba se dočkáme i v menších zařízeních. ARM by se měl začít bát.5)SVE vektory. Nevím co jsou zač. Ale rád se o nich něco přiučím.
6) 32bit zahodit. Souhlas. O tom žádná.
7)RiSC znám ale nevím o čem píšete.
8) 6 kanál stojí spousta křemíku a prodražuje celou platformu. Do desktopu nepatří.
9) O čem je to video? Na YT nekoukám.5. 7. 2023, 12:13 editováno autorem komentáře
-
Ad 1) AMD nedělá Little jádra jako Intel nebo ARM. Zen 4c je v stený Zen 4 jádro akorát použili High-density proces. Tedy ten proces který používá 99% všech vyrobených čipů včetně GPU. To jenom zmagořená x86 musí hnát frekvence na 6 GHz aby z toho dostali nějaký výkon když už zaostávají v IPC a architektuře obecně. AMD se konečně po 6 letech rozsvítilo, že v serverech nemusí plýtvat Low-density 6GHz křemíkem.
Možná víš že kdysi ARM demonstroval A72 která umí přes 4 GHz, jen ji prostě vyrobili s low-density 7nm TSMC jako Zen 2. Ale nikdo to nechtěl tak se na to vykašlali. V serverech ani noteboocích to nejde použít.
https://www.anandtech.com/show/14914/arm-tsmc-demo-7nm-chiplet-system-w-8-cortexa724ghz-on-cowos-interposer5) Ty neznáš SVE? 2048-bit revoluční vektorové instrukce nezávislé na délkce registrů. ARM už má druhou generaci SVE2 ve všech telefonech. Od malých Little jader až po našlápnuté serverové CPU. Dokonce i druhý nejrychlejší super počítač jede na SVE vektorech a díky tomu drtí GPU.
ARM už chystá nové verze nazvané SME / SME2, kdy místo V-vektorů to umí M- jako matice. V podstatě se dá říct, že na tom SME se dá postavit výpočetní GPU pro AI s instrukční sadou od ARMu. Naprostá pecka a revoluce. O tom se x86 ani nesnilo a proto Intel&AMD musí obcházet zaostalou x86 pomocí GPU akcelerátorů.
7) Já ti to pomůžu vysvětlit:
ARM = RISC
Zen 4 = uvnitř běží jako RISC
Takže když se vykašleš na tu HW-emulaci x86 z roku 1978 tak budeš mít co Kefalín? vyšší výkon a nižší spotřebu přece. -
Tradičně lehké nepřesnosti v letopočtech i tom ostatním :)
Koukám, že se opět vytahává ten Cortex-A72 na 4 GHz. Předtím byl podobný experiment s 3GH+ na Cortexu-A9. To bylo demo, pánové. Že to jádro v labu TSMC bylo přetaktované ve speciálním vzorku na 4 GHz je jedna věc, že v praxi jezdilo na ~2,4 GHz, ale není náhoda. Firmy nebudou uměle nechávat svoje procesory pomalejší, než musí, kdyby k tomu nebyl důvod.
A taky to byla jiná architektura než A76-A720/X1-X3 (to je odlišená architektonická větev od jiného týmu), IIRC s delší pipeline.
-
Ano, Apple M2 nebo Cortex X4 by klidně mohly běžet na 6 GHz kdyby byli ochotni se smířit s vyšším TDP. Stejné jádro, stejná pipeline, jen použili proces pro vysoké frekvence místo tradičního high-density, díky tomu mohli zvýšit voltáž a tranzistory se rychleji přepínají = najednou máš skoro dvojnásobnou frekvenci. Žádná černá magie za tím není.
Ale houby speciální vzorek. Jenom nerozumíš tomu jak funguje CPU a jeho pipeline. Tranzistor samotný dokáže běhat na 200 GHz, ale určující frekvence CPU je daná délkou onoho řetězce tranzistorů ve stage, resp její kritické cesty, nikoliv délkou pipeline. Délkou pipeline argumentují jenom ti co tomu ve skutečnosti vůbec nerozumí. Předpoklad že CPU s 18 stage pipeline musí mít vždy kratší stage než CPU s 10 stage je totiž zcela mylný. Může, ale nemusí. Zkracují se třeba pipeline pro násobení INT a přitom na frekvence to nemá žádný negativní vliv. Proč? Protože se MUL instrukce řeší pomocí paralelnějšího algoritmu, což umožňuje zkracovat pipeline bez dopadu na frekvence.
Zen 2 na 7nm TSMC na top frekvenci 4,7 GHz si vezme 20W jenom to jedno jádro. Takže je jasné že i ta úsporná A72 bez té HW emulace x86 CISCU si na těch 4,2 GHz vzala třeba 10W. Je logické že tohle do mobilu nikdo dát nemůže, zvlášť ne 4 jádra. Ale takový 8c Ryzen nemá problém dosáhnout 160W. Ani v serverech nemůžeš mít 64 jader se 640W a takovej Graviton 3 má TDP 100W a na jednu desku do 300W TDP se mu vlezou 3 sockety se 192 jádry (AMD potřebuje 400W TDP na pouhých 96 jader).
-
2,4 GHz A72 z mobilu a díky low-density najednou tradá ..... 4,2 GHz.
Jeden by řekl že to je důkaz.
Jenže to by někdo musel vědět jak se navrhuje low-power mobilní pipeline: její hlavní úkol jsou nízké volty 0,8 - 1,0V a při těch dosahovat co nejvyšší frekvence. To znamená krátké stage úplně stejně jako high-frekvency design. Proto low-power A72 je schopná běžet na vysokých frekvencích přes 4,2 GHz pokud je vyrobena na high-frekvency procesu (low-density) a pustí se do ní 1,45V. To je přesně to co ARM udělal.
Ale když někomu chybí elementární znalosti o CPU, tak to je fakt těžké. AMD v serverech dělá to samé když provozuje 64-jádrový 220W TDP Epyc a ty x86 Zen jádra mají spotřebu 3,5W při 0,8V a 2,5 GHz. Furt nedochází? Bergamo je další důkaz kdy AMD použitím high-density procesu zahodila vysoké frekvence a tím vytvořila čistě low-power CPU který nemůže běžet na vysokých frekvencích, ale je skoro dvakrát menší a tedy levnější na výrobu (což přesně dělají mobilní ARMy).
-
"Apple M2 nebo Cortex X4 by klidně mohly běžet na 6 GHz "
Ne. Nemohli.
Dál to nečtu a nereagují.
Ty informace vypadají fantasticky.
Ale ty co mohu ověřit jsou nepřesné a zavádějící polopravdy. Takže nevěřím ani těm co nemohu ověřit.EDIT
ALE jsem rád že pokrok běží na všech frontách.
ARM i x86.
Singularita bude.
intel se snad brzy vzpamatuje a taky šlápne na plyn.5. 7. 2023, 20:25 editováno autorem komentáře
-
1) a 3-4) Malá jádra iMHO nejsou principiálně špatně. Ta koncepce má svoje teoretické opodstatnění. Může dosáhnout vyšší ST i MT výkon v určité dané ploše a aspoň teoreticky takové CPU může být i víc energeticky efektivní. Je to díky tomu, že velká jádro se může specializovat na herní a ST výkon víc než univerzální jádro a malé nebo střední jádro se může specializovat na nízkou spotřebu nebo "throughput"MT výkon víc než univerzální jádro. Tuším jsem to zkoušel načrtnout v tomhle článku na začátku: https://www.cnews.cz/clanky/intel-alder-lake-male-jadro-gracemont-efficient-core-architektura-nejefektivnejsi-x86-jadro/
5) ARM přišel s trochu odlišnou koncepcí SIMD, než se doteď používala/používá. U SSEx a AVX/AVX2 a AVX-512 nebo u ARM NEON je daná šířka vektorových registrů (tedy kolik hodnot najednou instrukce zpracuje - 128, 256, 512 bitů) .
SVE (Scalable Vector Extension) místo toho přišlo s nápadem, že ty instrukce by měly virtuálně šířku až 2048 bitů, což by ale bylo v procesoru implementováno na mnohem menších jednotkách a mezi tím by byla nějaká míra abstrakce, aby programátor napsal aplikaci jenom jednou a pak to fungovalo na procesorech s různou šířkou vektorů. To je teorie, ale mezitím co jsem koukal se už stejně přišlo na to, že nejspíš pořád bude nutné psát kód zvlášť pro různé reálné fyzické šířky výpočetních jednotek, aby byl optimální. Takže nakonec to možná v praxi nebude moc rozdíl proti SSE/AVX/AVX512.
Jsou to dvě odlišené koncepce. Ta fixní verze SIMD (ovšem ne úplně fixní, protože se taky dá udělat třeba VX2 nebo AVX-512 na jednotkách s poloviční šířkou) je dlouhodobě osvědčená, víme, že funguje. SVE bylo dlouho jen na papíře, pak to bylo v HPC procesoru Fujitsu A64fx (s tím projektem asi ten celý vývoj souvisí) a až posledních pár let to dostala standardní jádra ARM.
IMHO se ještě teprve ukáže, jestli je to opravdu v něčem lepší (někde asi může být i negativum - ta větší abstrakce IMHO může znamenat, že při maximálním ručním ladění výkonu může ten škálovatelný variabilní vektor dopadnout hůř než fixní). Zatím bych spíš opatrně tipoval, že to bude nějak fungovat a prostě to budou dva alternativní přístupy současně používané v praxi. V autech jsme taky sto let měli jak vznětové, tak zážehové motory a bylo kravina o jednom z toho tvrdit, že je to revoluce, naprostý zázrak zatímco to druhé katastrofa, blé, vykopávka a šmejd, jako blouzní Jim Keller /Richie Rich/6ALU...
Například pořád tlačí to o "2048 bit" šířce. Jenomže ta je jenom virtuální. Fujistu ponecháme stranou, protože to není obecné CPU (zkuste si ho někde koupit...).
Jádro ARM Neoverse V1 má instrukce SVE, které umí jenom floating point data ale počítá je na jednotkách se šířkou 256 bitů, což tento maniak rád ignoruje. No a tím je daný výkon, který tím pádem je jenom jako u instrukcí AVX, které drtivá většina procesorů (Haswell+, Zen2+, tj. 2013-2019) počítá na 256bitových jednotkách.
V běžných zařízeních jádra ARM Cortex používají jenom 128bitové jednotky (už ale umí i SVE2, takže konečně i celočíselné výpočty pro multimedia), což už je na úrovni instrukcí SSE* na procesorech Intel Core 2 a AMD K10 (2006-2007).
-
Olšan ty SVE vektory vůbec nechápe.
"
SVE vektory umí virtuálně NEKONEČNOU délku vektoru, kdy v C++ lze použít typ SIZELESS. To umožňuje kompilátoru označit data na kterých má provést autovektorizaci. Už tohle samo o sobě je REVOLUCE.
"
Dále SVE oddělilo délku vektoru od samotné instrukce. Typicky fixní vektory jako SSE a AVX musí mít definovanou délku třeba FADD_128SSE takže pro 3 různé délky musí mít x86 také 3 různé instrukce (128 / 256 / 512-bit). Protože ARM SVE umí 16 různých délek (od 128-bit až do 2048-bit s krokem 128-bit) což by bylo naprosté mrhání kodováním instrukcí (takové 1920-bit by zbytečně zabíraly místo a nejspíš je nikdo nikdy nepoužije, protože tam jsou kvůli orthogonalitě ISA), tak CPU nastaví 128-bit mode a pak všechny SVE jsou automaticky zpracovány v 128-bit šířce. Tím se ARM vyhne tomu x86 peklu s duplikovanými instrukcemi jejichž jediný rozdíl je délka vektoru. Je to geniální řešení protože CPU má stejně fyzicky pouze jednu délku SIMD výpočetních jednotek - viz třeba Zen 4 má 256-bit SIMD a AVX512 instrukce musí vnitřně rozkládat na 2x256-bit jak Potěmkinova vesnice. Kdyby x86 uměla tyto revoluční vektory s flexibilní délkou SVE tak by si AMD nastavilo 256-bit mode pro AVX512 a hotovo vyřešeno. Tedy dizajn FPU/SIMD by mohl být mnohem jednodušší, rychlejší, méně tranzistorů, méně promrhané energie atd.
"
Další výhoda SVE je že budoucí CPU s 512-bit SVE jednotkami bude zpracovávat dnešní SW 4x rychleji, protože dnes ARM má většinou 128-bit SIMD SVE (4x 128-bit takže výkon to má stejný (o něco lepší kvůli skalárním instr) jako Zen 4 který má 2x256-bit). To třeba x86 neumí, protože AVX512 neumí zrychlit starší 128-bit SSE aby běželi 4x rychleji. Revoluční SVE to umí a teoreticky na 2048-bit SVE ten SW poběží 16x rychleji. Prostě geniální.
"
SVE jsou revoluční a ten kdo tvrdí že ne, tak nerozumí tomu jak funguje CPU. Třeba úplně nový RISC-V fixní SIMD ala x86 rovnou zavrhl a vydal se rovnou cestou flexibilních vektorů SVE/RVV. Dokonce ještě vylepšíli SVE tím, že jejich RVV umí flexibilně měnit i počet samotných registrů a počet elementů ve vektoru. A to je podle mne správná cesta. Už jenom tím, že tyto flexibilní vektory lze dle potřeby degradovat do těch fixních když je potřeba zpětná kompatibilita při konverzi SW z jedné ISA na druhou. Prostě geniální revoluce.
"
Fixní vektory x86 jsou technologie z 1990 ala MMX. Olšan třeba nezmíní že Intel Alder Lake backportoval VNNI instrukce z AVX512 do AVX2 kvůli těm malým jádrům Atom Gracemont. A nový Meteorlake má backportovat údajně další AVX512 instrukce do AVX2 a tím vytvořil v podstatě třetí a čtvrtou verzi 256-bit AVX, což je naprostý mega bordel, protože tyhle verze zase nepodporuje žádný CPU od AMD. Intel to tradičně dělá aby poškodil AMD, protože on je vlastník x86. -
Zkus napsat do ARMu těm inženýrům co navrhovali revoluční SVE, že neví co dělají když nutí stamiliardovou ARM infrastrukturu do zcela experimentálních a bůh ví jestli funkčních SVE/SVE2/SME/SME2 vektorů.
"
A dej vědět co ti odpoví ať se tady pobavíme :D
"
A při vší geniálnosti bys mohl konečně odpovědět na to backportování VNNI instrukcí z AVX512 do AVX2. Zejména jestli to bude podporovat i AMD nebo SW bude muset podporovat všechny verze, jak VNNI pro AVX512 pro AMD a zároveň i VNNI pro Intelácké 256-bit AVX, takže z toho bude ještě větší bordel než byl (a to Arrow lake má přidat ještě další backportované instrukce VNNI).(přesně tenhle problém řeší ty SVE vektory protože instrukce jsou nezávislé na délce vektoru, který může být cokoliv od 128-bit až po 2048-bit s krokem 128-bit)
-
Backportování instrukcí VNNI je proto, že Gracemont nemá 512bit registry. No a? Neznamená to v tomhle kontextu absolutně nic o kvalitách nebo nekvalitách SVE(2) nebo AVX-512. Na každou kravinu taky reagovat nemůžu, to bych tu po tom vašem nájezdu toho musel sepsat násobně víc (a že už jsem tu vytapetoval slušně i tak).
BTW k tomu údajnému nerozumění SIMD... to my říká někdo, kdo zřejmě nevěděl, co jsou shuffle/permute instrukce, když jsem je zmínil, nebo jehož představa o kódu, který se SIMDuje, je "65 tisíckrát se provede násobení"? https://www.cnews.cz/clanky/amd-vydalo-96jadrove-procesory-s-3d-v-cache-epyc-genoa-x-96-jader-a-vic-nez-gigabajt-cache/nazory/
8. 7. 2023, 15:06 editováno autorem komentáře
-
Takže odborník tvrdí že backportování VNNI a vytvoření dvou nových verzí AVX2(256-bit), které ovšem AMD nebude podporovat dalších 5 let a bůhví jestli vůbec někdy bude..... takže to neznamená vůbec nic. Něco jako fragmentace ISA asi odborníkovi nic neříká :D
A že přesně tenhle problém řeší SVE, protože odděluje instrukci od délky vektoru, to je náhoda že na to neodpoví. Přece nemůže reagovat na každou kravinu (kde Kravina = moje pravdivé tvrzení, které dokazuje že se Olšan mýlí).
Odborník co nikdy nedělal v assembleru si někde vygooglil Shuffle instrukci z AVX512 a prej je to zásadní instrukce odlišná od Gather/scatter aniž by mu došlo že to je v podstatě vektorovej MOV s maskou. To je tak když někdo nezná základy a neví že MOV mezi registry je naprosto rutinní záležitost na každém 8-bit MCU, která je v CPU stejně eliminována při Rename. A ještě tohle na sebe vytáhne, to je neuvěřitelný....
Nicméně přiznávám svou chybu. Debatovat s Olšanem o tom jak zakodovat vektorové instrukce když nezná naprosté základy bylo opravdu jako házet hrách na zeď. Kdejakej študent má jako semestrální práci ve škole za úkol vytvořit svou vlastní ISA a dá se s ním o tomhle bavit a tady "odborník na CPU" totálně nechytačka. Já bych tam nezměnil ani čárku, protože to je prostě ten historický souboj předávání dat přes zásobník vs. registry. A ještě to vytáhne jako důkaz své chytrosti, to je neuvěřitelný... :D
Vsadím se že ani neví co to ten zásobník je, a právě týrá google.
Schválně jestli se dočkáme odpovědi zda ty SVE principielně řeší to backportování VNNI a tedy zabraňuje fragmentaci ISA na hromadu různých verzí.
-
Ono je to dilema, no. Člověk nemůže reagovat na všechny případy "someone is wrong on the internet", zvlášť když je to jenom komentář, kde by ideálně bylo třeba pamatovat, že ho může napsat kdokoliv a může to teda být blbina.
Jenže zase když se to tváří hodně sebevědomě, tak člověk musí přemýšlet nad tím, že to třeba někdo bude číst a mohl by brát vážně, takže korigovat by to ideálně chtělo...
-
principiálně tě chapu, ale vzhledem k tomu, že jsme si tím samým už prošli před par lety na diitu a vysledkem bylo, že nakonec dostal dotyčný ban, stejně jako Maudit tady na EHW .
Tehdy se mu argumentů dostalo bohatě, ostatně stačí trochu hledat ve starších diskuzich na diit, ale podobné jako v případě Maudita to nikam nevedlo. Ten člověk se chová jako fanatik, pořád omílá ty svoje "moudra" a ještě má tu drzost označit ostatní diskutující za hlupáky. Chvíli to bylo i vtipné, ale brzy se ta zaseknutá gramodeska omrzí a posléze už jsou ty příspěvky jenom obtěžující a zbytečně tady s nima tapetuje diskuze...
Pointu jsme všichni davno pochopili, Apple je nejlepší na světě, ostatni x86 vyrobci jsou looseři, a IPC ARMů s 8 ALU drti výkonem všechy :-D
-
Jan Olšan, chápu to dilema. Navíc čím méně restrikcí a banování, tím větší svoboda projevu a možná pomoci někomu jinému pochopit jiný úhel pohledu. Na druhé straně fanatik neposlouchá a zaslepeně jede jen to svoje. S tím “ když se to tváří hodně sebevědomě” jsi to trefil. Ten 2048 bit trotl měl možnost pochopit, že je vedle, ale i přesto tu tapetuje hlouposti pořád dokola a ještě se snaží o manipulaci. Co s takovým otravným hlupáčkem..
-
Urážet redaktora nenecháme!
Bez maniaka by tu byla možná trochu nuda.
Ale bez redaktora by tu nebylo nic.
I kdyby neměl extrémní znalosti architektur, tak jeho články se čtou výborně. Na rozdíl od komentářů pod nimi.
Ale věřím spíš panu Olšanovi, protože umí velice přesně popsat skutečnost. Tak jak je. -
"Malá jádra iMHO nejsou principiálně špatně."
Je třeba rozlišovat malá jádra (já říkám LITTLE)
A paradigma big.LITTLE (já říkám kripl)ZEN 4c umožňuje zvýšit počet jader, čím přibližuje singularitu. Je to správná cesta. OK
Big.LITTLE nic nepřináší. Jen zlevňuje CPU.
Takže máme lepší poměr cena/výkon. Mooreho zákon je sice splněn (Při stejné ceně bude nová generace výkonnější), ale o pokroku se mluvit nedá. Jen co zabere času to vyladit. Kdyby lidstvo raději hledalo cestu jak se posunout dále. Ale tohle je takové přešlapování na místě.Bohužel pan Moore už není mezi námi.
R.I.P.
Ale stále platí, že každé 2 roky stoupne výkon na dvojnásobek.
A když se to x86 nepodaří. Tak ho ARM dožene. A možná i nahradí. Cesta vpřed se vždy najde.
Návody a tipy
23. 10. 2024
| online
31. 7. 2024
| online
6. 7. 2024
| online
ČLÁNKY DO MAILU