Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Já tomu SVE2 nerozumím. Jak můžou podporovat 128-bit až po 2048 bit? Není nějaký překlep když nejnověrší Ryzeny 5000 mají 256-bit a drtí Intel i jeho AVX512?
Jak to bude kompatibilní v rámci SW? To se bude muset být pro každou šířku SVE2 jiná verze SW? To je potom naprosto odsouzeno k zániku. Ty ARMy jdou do kopru...
Překlep to není: VE and SVE2 define 32 scalable vector registers. Silicon partners can choose a suitable vector length design implementation for hardware that varies between 128 bits and 2048 bits, at 128-bit increments. The advantage of SVE and SVE2 is that only one vector instruction set uses the scalable variables.
The SVE design concept enables developers to write and build software once, then run the same binaries on different AArch64 hardware with various SVE vector length implementations. The portability of the binaries means that developers do not have to know the vector length implementation for their system. Removing the requirement to rebuild binaries allows software to be ported more easily.
https://developer.arm.com/tools-and-software/server-and-hpc/compile/arm-...
Díky za odkaz. Velmi zajímavé. Vypadá to že to není aprílový vtip.
Počkat. Takže zatímco x86 se 128 bit SSE, 256 bit AVX2 a nakonec 512 bit AVX512 potřebuje pokaždé rekompilovat na novější instrukční sadu aby ji mohl využít, tak identický ARMv9 kód bude umět běžet jak na smart phonu se 128 bit šířkou tak i zároveň na superpočítači se 2048 bit?
Napíšu aplikaci, zkompiluji dnes a bude to běžet třeba za 10 let na pořádném CPU 20x rychleji protože to automaticky využije plných 2048 bit které budou v budoucnu dostupné? To by ovšem byla docela zásadní věc. Nechystá AMD něco podobného?
> Napíšu aplikaci, zkompiluji dnes a bude to běžet třeba za 10 let na pořádném CPU 20x rychleji protože to automaticky využije plných 2048 bit které budou v budoucnu dostupné?
Teoreticky - SVE je udelano (AFAIK) tak, ze ma 32 SIMD registru, ktere maji nejakou "implementation defined" (maximalni) delku. Tu delku lze nejakymi instrukcemi limitovat na nasobky 128bit az do toho maxima. IOW, neni to "automaticky" flexibilni - flexibilni je jenom ta delka SIMD, software se taky musi umet prizpusobit.
RISC-V ma tohle vyreseno jeste elegantneji a vic "high-level" - SIMD vymenili za vektory. Mate jednu instrukci kterou mu reknete "hele od tedka budou vsechny vektorove instrukce pracovat s 123 prvky", a pak vsechny nasledujici vektorove instrukce pracuji se 123 prvky :) jak si to CPU uvnitr rozlozi na realne uops, jde uplne mimo programatora, CPU muze mit treba 128ibit SIMD, nebo taky nemit zadnej SIMD a delat to po jednom prvku. Ma to svoje vyhody (maximalne flexibilni, prakticky bez limitu na delku SIMD) a nevyhody...
> Nechystá AMD něco podobného?
AMD chysta AVX512 v Zen4 (jsem slysel). x86 v tomhle jasne zaspalo dobu, uz davno meli uvest neco na styl SVE... A IMO taky uvedou, driv nebo pozdeji. Kazdou novou iteraci AVX je dekoder x86 porad vetsi monstrum.
Tak tomu říkám opověď odborníka. Když SVE má 32 SIMD registrů, tak kolik měl ten starý Neon? A kolik má x86 (asi víc když mají výkonější procáky ne)?
Předpokládám že registr je vnitří paměť něco jako L0 keš a čím víc tím líp. Něco takového jsme řešili při programování Atmelů, ale tam to bylo jen 8 bit. Dobře, tak x86 má víc registrů, takže to výkonově vyrovná ty flexibilnější SVE vektory ARMu. Sice AVX jsou větší binec ale programátoři stejně používají knihovny s hotovými funkcemi, takže je to asi jedno.
Důležitý je výkon! Akorát co znamenala ta zmínka že nejrychlejší super počítač je nějaký ARM Fugaku. To jako že ARM je výkonější než XEON nebo EPYC? To asi těžko.
Tak interně maj procesory registrů spoustu, používají je pro out of order execution. Ale instrukční sada má vliv na IPC, např. na rychlost dekódování instrukcí (můžeš mít registrů a ALU, kolik chceš, když to nestíháš krmit).
Nejrychlejší počítač se staví na tom, co je nejrychlejší. Přece nebudeš pro požadovaný výkon platit 2x tolik za 2x víc slabších procesorů (zjednodušeně - ona dost roste taky infrastruktura na jejich efektivní propojení). Tady má ARM výhodu flexibility instrukční sady - Japonci si ji navrhli ve spolupráci s firmou ARM, takže ji udělali na míru maximálnímu výkonu superpočítačů (a ARM si zajistil, aby to šlo ořezaně implementovat i do mobilů). V x86 žádná takováhle diskuze není - platí, co (ne)vymyslí Intel, jinak jseš nekompatiblní se standardem (autorem x86). (Když nepočítám výjimku v podobě amd64, kdy Intel plánoval opuštění x86, a pak se musel narychlo vracet.)
EDIT: Proč je 512 bitů na ARM efektivnější než na x86 - protože Intel to jen připlácl k již tak dost zastaralé architektuře a sám to ve své vlastní implementaci nestíhá uchladit (musí hodně podtaktovat). Kdežto ARM už v základu cílí na spotřebu a Japonci samozřejmě nastudovali, jak si s 512 bity poradili ti před nima, takže se z chyb poučili a udělali to líp. (Proto já osobně nevyčítám, že x86 je v některých věcech méně efektivní a promyšlený než ARM - podobně jako ARM méně než RISC-V. Tady má výhodu ten, co přijde později, že se poučil z chyb předchůdců - i když zas předchůdci se stihnou mezitím rozšířit na trhu, tak záleží, jak zvládnou se tam udržet.)
Japonci si to vyvinuli společně s ARMem, zajímavé. To jako může přijít kdokoli do ARMu a říct hele potřebujeme nové instrukce, tak to koukejte začlenit do instrukční sady?
To mi furt hlava nebere. Intel s AMD si jdou po krku a prosadí se lepší/silnější, takže Intel si protlačil AVX512. To mi přijde darwinovsky efektivní.
A tom ARMu si jako řekli, hele tady nám kluci šikmooký navrhli 2048 bit vekrory pro super počítače, tak pojdme z toho udělat standard ať z toho benefitují uplně všichni - od pračky, přes mobily až po servery? To jako že si ARMy nejdou darwinovsky po krku, ale naopak spolupracují?
Mne jako Atmelistu zajímá jestli se ARMv9 objeví i v Cortex M co se dává do mikrokontrolérů. Že bych přešel z 8-bit Atmelu rovnou na 2048 bit ARM? Ty krávo to bude skok jako prase
Áno ARMv9 sa objaví aj v Cortex-M a nie, nebude to reálny skok na 2048bit. Do tých Cortex-M CPU implementujú prinajlepšom 128bit, veľmi silne pochybujem že pôjdu ďalej, keďže to zbytočne zaberie kremík, ktorý k účelu pre ktorý vzniká Cortex-M nie je potrebný. A áno spustíte aj na tokom CPU aplikáciu s SVE2, len ten výkon nebude až tak slávny ako si myslíte.
Skúste si najprv niečo o Cortex-M a všeobecne ARM architektúre naštudovať lebo občas tie vaše dotazy sú také ako keby ste len vedeli že ARM existuje, ale už nie, aspoň povrchne, ako funguje.
Ano, na architektuře ARM spolu výrobci spolupracují (proto se tak vyvíjí). Nové instrukce samozřejmě musí mít smysl (ARM měl do té doby jen 128bit NEON, kdežto Intel už AVX512) a důležitá podmínka je, že i ostatní výrobci budou moci použít nové instrukce (jak jsem to pochopil, tak Apple akceleraci emulace x86 udělal jiný režimem práce s pamětí - pro emulaci strong memory modelu x86 - a vyhl se tak potřebě přidávat vlastní instrukce).
A ten Neon se liší od SVE jen šířkou nebo tam jsou i nějaké nové intrukce které by mohly přinést zrychlení i pro 128 bit jednotky SVE?
Ale ten strong memory model x86 je lepší než to co má ARm ne?
Vypadá to hezky, ale doufám, že se už začne víc prosazovat RISC-V, nebo bychom tu zanedlouho mohli mít stejný monopol jako s Intelem.
Naštěstí i v oblasti mikrokontrolérů už existují RISC-V varianty a to i v podobě ESP32 (sice je to zatím méně výkonné než armové verze, ale co není může brzo být). Příští mikrokontrolér, který si pořídím, už musí být RISC-V, menší rychlost nebo výkon tam nehraje roli, spíš možnosti kolem deep-sleep atd.
Na strane x86 je to este komplikovanejsie, pretoze rozdiel medzi SEE, AVX2 a AVX512 nie je len v sirke vektora, ale aj v mnozine podporovanych operacii. Zhruba najmensi bordel v tom bol niekde na urovni SSE3 / prvych AVX a potom to Intel typicky po Intelovsky rozbordelizoval
Predstav si, ze mas k dispozici instrukci na zpusob "secti tyhle dve pole o delce max 2048bit a vysledek dej to do tretiho." Pokud mas megascitacku, buch, hotovo. Pokud vyrobce CPU setril, bude to scitat na nekolikrat, ale o tom nebudes vedet, kod bude stejny. Plus specka rika, ze musi zvladat aspon tech 128bit, takze to bude rychlejsi, nez to tocit po jednom prvku.
Aha, takže jestli tomu dobře rozumím tak to bude automaticky rekurzivně zpracovávat vektory. S tím že 256 bit bude 2x rychlejší než 128 bit atd. A to je dělané jako SW smyčka kompilerem nebo se o to stará HW v CPU?
Jenže to by znamenalo že 2048 bit .... bude teoreticky 16x rychlejší než nynější 128 bit NEON Armv8.
Taky by to znamenalo že 2048 bit .... bude 4x rychlejší než Intel s jeho 512 bit AVX.
Taky se nabízí otázka jestli to bude umět použít vícero FPU pro zpracování jedné dlouhé instrukce. Něco jako uměl Ryzen 1000 který měl jen 128 bit ale měl dvě FPU jednotky a uměl je spřáhnout do jako jedné a tak vykonat i 256 bit AVX2 instrukci.
Teoreticky;) Prakticky bude zalezet na tom, jestli budete mit akorat dlouhy data, atd. Ale snaha je udelat to tak, ze nebude potreba to optimalizovat pro kazdou verzi ARM9, co kdo vyda, ale aby tam stejny kod bezel co nejrychlejc to pujde. Cekal bych, ze s ladenim mensich procesu budou vyrobci pridavat vetsi a vetsi jednotky, pripadne budou mit ruzne verze tehoz, pro levny mobil 128bit, pro drahy 512, do superpocitace 2048.
To jako mobil bude umět 512 bit a bude teda výkonější než můj herní Ryzen co umí 256 bit???
Jaké paměti vůbec používají dnešní mobily, to bude nějaké prehistorické DDR2, ne? To by v životě nemohli stíhat krmit daty.
Nektere tel. uz pouzivaji LPDDR5, prvni link co mi vyhodilo duckduckgo:
https://www.smartprix.com/bytes/lpddr5-ram-phones/
To si děláš prdel, no fakt, Samsung S20 měl DDR5 už od minulého roku. To snad není možný
Ale je... dalsi uz budou mit LPDDR7 a 12 ALU ;-)
nepliesť si LPDDR a DDR to sú odlišné technológie.
A áno LPDDR predbieha vo vývoji číselne DDR
LPDDR předpokládám že má nižší výkon, nižší frekvence a nižší latence než DDR? Aha, už jsem se lekl že by mobil měl lepší RAMky, co je fakt blbost.
To "LP" v názvu znamená Low Power (nízká spotřeba). Proto je to primárně na výkon/spotřeba v mobilech. Ale už se rozšířily tyhle RAMky i do notebooků, kde tě taky spotřeba zajímá (LPDDR používaly už Macbooky s Intel CPU). V novém Apple M1 má výhodu LPDDR, že ten stejný výkon je rozdělený do více užších kanálů, což ladí s out of order execution, kdy je možné paralelně přečíst/zapsat data v různých místech v RAM (řeší problém, že co se nevejde do cache CPU, tak tam čekáš na RAMku).
Predpoklad o frekvencii a výkone nie je úplne správny. Ako píše Ladis, LP je Low Power. To je dosahované primárne nižším napätím, ktoré si môžu dovoliť, nakoľko sú tieto pamäte hneď pri CPU (podobne ako GDDR pri GPU) čo tiež znižuje latencie.
To, ktoré pamäte sú lepšie, je ťažko povedať, ale ak sa pozrieme na pomer výkon/spotreba tak tie v mobiloch (teda LPDDR) sú lepšie ako klasické DDR
https://en.wikipedia.org/wiki/LPDDR
Aha. Takže pitomej mobil má LPDDR5 na 6400 MHz což je dvakrát tolik než mám já s Ryzenem a DDR4-3200? A ještě je to úspornější? Hergot proč nemáme DDR5 v kompech dávno před mobilama?
Pretože pre PC, resp. DDR je potrebné riešiť integritu prenosu medzi CPU a RAM keďže sú tam 2 spojenia ktoré závisia na tom či to správne sadne pri skladaní (socket procesora a socket DIMM modulu) plus ešte na samotnom module je minimálne jedno ďalšie pripojenie z chipu na plošný spoj. Pri LPDDR a GDDR je to jednoduchšie, keďže v oboch prípadoch sa jedná o pamäte priamo pajkované blízsko výpočtovej jednotky, čo znižuje spotrebu pamätí (signál na kratšiu vzdialenosť nemusí byť pri jeho generovaní tak silný).
Takže v skratke:
DDR - univerzálne vymeniteľné pamäťové moduly, ktoré musia byť silne kompatibilné so skoro ľubovoľným HW
LPDDR - low power verzia DDR, ktorá ale už tak nerieši kompatibilitu, keďže nie sú vymeniteľné, takže kompatibilita sa zabezpečuje už pri vývoji SoC. Sústreďujú sa tiež na čo najnižšiu latenciu
GDDR - pamäte primárne zamerané na obrovský sekvenčný zápis, kde nevadí vyššia latencia (a že ju GDDR oproti DDR majú fakt vyššiu)
Díky, zajímavé info,.
Takže LPDDR5 v mobilu z roku 2020 má 6400 MHz a nižší latence než bude mít Zen 4 s obyč DDR5 v roce 2022??????
Ale v tom Zenu si zas budeš moci časem přidat víc RAM. Ten mobil/notebook s připájenou pak leda prodat a koupit nový (tedy, teď je na Živě, jak nějakej Číňan si v Apple Mac Mini sám přepájel RAM na dvojnásobek a disk na čtyřnásobek, ale to už chce umět s pájkou).
To máš pravdu. Ale stejně bych chtěl výkon od připájených RAMek a pak mít možnost do slotu rozšířit o pomalejší moduly kdyby něco. To mi přijde nejlepší kombinace.
Len to už je trochu komplikovanejšie, keďže by to museli byť rozdielne radiče a tým pádom by musela byť aj architektúra pamäťového subsystému iná, kde by sa museli tie pripájené RAM správa ako ďalšia vrstva cache, neviem si predstaviť ako by mal procesor pracovať s rôznymi typmi pamäte rovnakým spôsobom
Teoreticky to bude 16x výkonnejšie, prakticky to spotrebuje aspoň 16x viac tranzistorov v tejto jednotke, čo zvýši cenu za celý procesor a zvýši pravdepodobnosť vadne vyrobeného procesora.
Problém bude spíš kolik SW dokáže vůbec tak široké vektory využít.
256 bit AVX2 v Ryzenech jsou vektor čtyř double floatů (64 bit).
AVX512 je osm doublů a jsou problémy na to optimalizovat SW.
2048 bit je brutálních 32 doublů, což snad mimo super počítače ani využít nejde.
Leda že by ARM měl vizi že si každý v mobilu na pozadí bude počítat simulaci nukleární exploze :D Jako výkonu není nikdy dost, ale tohle mi přijde vyloženě pitomé.
Pri spracovaní 8K videa aj tých 2048 bitov môže byť málo.
Největší problém s SSE a AVX je v tom, že jsou to zprasené instrukční sady (stylu SWIR). Takže spousta věcí se pro ně řeší ručně, a to s každou generací v zásadě znovu od začátku. Naopak smysl řešení jako je SVE nebo RV64V je v tom, že pro ně mnohem snáze dokážou generovat kód kompilátory a že se to musejí naučit pouze jednou (kvůli nezávislosti kódu na šířce slova).
Takže tím chceš říct, že když ARMv9 je na dalších 10 let jako základ, tak budou mít mobily lepší instrukční sadu než třeba můj Ryzen?
Stejně ARM je RISC takže to přece nemůže být tak výkonné jako CISC. Přece jedna CISC instrukce je jako 10-20 RISCových ne? V tom je to tajemství x86 výkonu jak to vidím já. Atmely jsou taky RISC, je to jednoduché a nic to nežere, ale Win10 na tom nespustím ani kdybych se rozkrájel.
1. Ano, proto např. Apple už přeběhl od x86 k ARM.
2. Dřív to platilo, dnes je ale komplexnost instrukcí CISC již brzdou - hlavně v dekódování instrukcí (nestíháš krmit libovolně velké množství ALU a registrů pro out of order execution - vykonání více intrukcí současně).
3. Windows spustíš na RISC procesorech. Win10 na ARM, starší podporovaly Alpha, MIPS a PowerPC.
Proč je pak Windows 10 na armovém SQ1/2 násobně rychlejší než na Surface Go s Intelem?
To si děláš srandu ne? Máš nějaký důkaz že pomalý Arm je rychlejší než x86 Intel? To asi těžko.
Vysvětlení je jednoduché. V těhle ultraportable pracuješ s TDP, které je doménou ARMu. Intel tam je neskutečně přiškrcen (když nepočítám pár sekund až desítek sekund, než se zahřeje).
V mobilech a ultrapotrable jo. Ale jinak Arm nemá v notebocích šanci IMHO
Je to způsob, jak dosáhnout kompatibilitu mezi různě výkonnými procesory, nebo to má nějaký jiný praktický význam?
Asi jo, kvůli kompatibilitě. Jsem se díval, že ten Fugaku používá SVE instrukce, ale asi to není kompatibilní s těma ARMovýma vektorama Neon co se používají v mobilech.
Tedy jestli to dobře chápu, tak ARMv9 je pokus nacpat SVE instrukce vyvinuté pro Japonský super počítač do všech mobilů. Takže to bude mít instrukce lepší než x86? A tedy vyšší výkon??? To nám ARM chce nakukat že mobil bude mít vyšší výkon než herní PC?
To asi ne, ale pokud bude "procesor/jádro" alespoň předstírat, že umí dlouhé vektory, tak se vyhnou problémům s Big Little konceptem, který má teď Intel.
Tak to je geniální postřeh, to mě nenapadlo. Takže zatímco Intel musí deaktivovat AVX512 aby mu běhalo s těmi menšími Atom jádry (snad až na SSE musel degradovat?), tak ARM bude mít různě výkonná big.Little jádra, ale pro OS budou podporovat stejnou instrukční sadu, jen různě rychle. Hm. Z toho asi Intel nebude mít radost.
Ten moderní Atom bude podporovat i AVX2. Degradace na SSE by byla šílenost.
Jinými slovy Intel bude muset vypnout AVX512 a zdegraguje vektory na 256 bit jako má AMD.
A mobily budou umět 2048 bit na malých i velkých jádrech? To přece není možný aby ty pomalé ARM sračky měli takovou výhodu oproti desktopu.
Uvidíme co Intel, ale mobil může mít klidně 4096 bit, ale kvůli spotřebě leda tak při frekvenci 300 MHz. Praxe ukáže. Já jsem hlavně zvědavý jak pojme AVX-512 AMD, které je doteď úspěšně ignorovalo a nijak moc mu to neublížilo.
Já myslím že se pleteš. GPU dnes běží na 2,5 GHz a mají kolem 10 000 CU přičemž každé CU zvládne zpracovat vektor. Takže 300 MHz je nesmysl, nicméně na 5 GHz to asi taky nemá šanci běhat.
Ještěže ARM neprodává CPU v krámě protože to by klasický BFU radši sáhnul po 2048 bit ARMu než po 512 bit Intelu nebo AMD. ARM se byl školit u Intelu na marketingu ne? :)
ARM nejen že neprodává CPU v krámě, on je ani nevyrábí ;-) O Intel se strachuješ oprávněně, ale zatím v současné vysoké poptávce těží z velkých výrobních kapacit (lidi koupí i horší procesory). AMD taky hodně vyrábí (mimochodem více, než by zvládl, kdyby furt vlastnil továrny GlobalFoundries), akorát se soustředí na jiné segmenty - jako servery a konzole. Uvidímě, až se světová situace uklidní.
A kdo ty Army navrhuje? To jsou nějací externisti v důchodu nebo co? Nebo si to navrhuje každý sám a společné jsou jenom instrukce?
Můžeš si zaplatit jen za instrukční sadu a navrhnout CPU jádra sám (např. Apple). Nebo si licencuješ hotová jádra, která si pak s dalšími koprocesory (např. GPU a kódování videa) zahrneš do svého SoC, a ten si vyrobíš (necháš vyrobit, např. v TSMC). Někteří takové výsledné SoC prodávají ostatním (Qualcomm, MediaTek), někteří je používají jen pro svoje zařízení (Samsung Exynos, Kyrin u Huawei, než mu dal Trump ban).
Procesory ARM už dávno nie sú len pomalé procesory v mobiloch, ale sú to aj výkonné CPU v superpočítačoch a keď majú zvládať enkódovať 8K 60fps alebo 4K 120fps, tak ten výkon treba. Neviem čo je na tom zvláštne.
Na PC až tak často ľudia neenkódujú videá, takže veľké vektory nie sú vždy výhra. Ako tu ale už bolo napísané, širší vektor rovná sa veľká spotreba kremíku, ktorú ale výrobcovia už nebudú ochotný vždy akceptovať, kvôli výťažnosti z daného procesu a následnej ekonomickej stránke
Zapomínáš, že rychlý vs pomalý jsou velmi relativní pojmy, a existují v nějakém kontextu. Takhle spatra narychlo mě napadají hned 3 kritéria:
- spotřeba
- odpadní teplo
- plocha křemíku
ARM je "rychlejší" než Intel při hodnocení ve vztahu ke všem třem; Intel je dnes rychlejší jen v absolutních číslech při stejném počtu jader vyšších řad, která ale jsou mnohem větší (a to se bavíme o počtu tranzistorů vyšším o řád), mají větší spotřebu, a mají vyšší teploty, a jsou v pořizovací ceně i provozních nákladech významně dražší. V momentě, kdy potřebuješ řešit efektivitu / rozměry / spotřebu / chlazení, je ARM ve všech ohledech jednoznačně lepší.
Tak jasně, do kalkulaček a mobilů jedině ARM. Když chceš absolutní výkon tak nic jiného než x86 nemá šanci, to je jasné.
Ten Japonský super počítač je nejrychlejší na světě, ale zapoměli dodat že jen mezi ARMy :D
Nezapomněli. Je nejrychlejší nejen mezi ARMy a x86, ale i mezi GPU superpočítači (tak byl právě navržen, aby měl výkon GPU superpočítačů, ale šlo na něm spouštět obecný kód - ne upravený na omezené možnosti GPU).
Tak to si ale teď děláš srandu ne? Jak může být nějaký Arm rychlejší než serverový AMD Epyc kombinovaný s hromadou připojených GPU.
EPYC + hromada GPU je rychlejší, proto se taky GPU servery staví na něm (a ne na podřadném Intelu). Nicméně 1) postavit superpočítač trvá roky, takže EPYC tam teprve uvidíš, a 2) zadání tohoto superpočítače bylo, že má jít o superpočítač s obecným CPU, bez nutnosti upravovat kód na omezené možnosti GPU (něco GPU oproti CPU neumí, něco jo ale ne efektivně; nebo prostě jen je potřeba kombinovat výpočet s kódem na CPU a nechceš se brzdit výměnou dat mezi CPU a GPU).
Jinak obecně ohledně CPU výkonu: superpočítač má extrémní paralelizaci výpočtů, proto tě nezajímá single výkon, jen ten multi. Tedy je jedno, jestli tam bude potřeba 2x více ARMů pro stejný výkon oproti x86, důležita je jen výsledná spotřeba (co zvládneš uchladit) - a jako bonus cena (vlastní CPU bude levnější, protože neplatíš marži někomu dalšímu).
Takže si všichni začnou vyrábět vlastní CPU a na Intel s AMD se vykašlou jako ti Japonci?
Podle dokumentace ARMu je SVE ARMem navržená vektorová jednotka, kterou chtějí doplnit či spíš nahradit NEON, protože proti němu má údajne podstatně víc ortogonální sadu instrukcí a lepší operace s vektory. Fugaku je jen první (a zatím asi jediný) procesor, co to implementoval, nicméně v platformách Neoverse má SVE být standardně.
A nevíš náhodou jak je SVE2 porovnatelné s AVX2 které používá AMD? Je to horší, lepší a v čem?
https://www.youtube.com/watch?v=hzfN-E5k5W0
V tom videu na YT mluvili o tom že umí akceleraci umělé inteligence a BFloat16. Co si pod tím mám představit? AVX2 tady je už dlouho, takže AI nejspíš neumí vůbec. Znamená to tedy, že ARMv9 jako přináší nejen širší vektory ale i pokročilejší instrukce??? To jako nové Ryzeny 5000 budou zaostávat za pitomýma mobilama z čajny?
Vzhledem k tomu, že neexistuje jediná skutečná implementace, tak tohle je velmi předčasná otázka :-)
Zeptám se obráceně. Umí dnes Intel nebo AMD ten Bfloat16?
V tom videu ten chlápek z Mediateku zmiňoval že procesory ARMv9 dodají již letos. To by znamenalo že letošní Samsung S22 bude umět 2048 bit i s podporou bfloat16 letos. Pomalé ARM sračky budou o něco méně pomalejší ARM sračky :D
J. Olšan správně napsal, že ty maximální šířky budou mířené primárně do super počítačů a že představují potenciál do budoucna, který můžou a nemusí využít. Záleží, jak to bude efektivní: výkon/spotřeba. Když vidíš, jak se Intelí CPU smaží už při 512bit vektorech i se správně dimenzovaným chlazením... A smartphony žádné aktivní chlazení nemají a mít nebudou...
Takže mi jako chcete říct, že ARMv9 bude podporovat brutálně výkonné CPU pro superpočítače s naprosto šílenou šířkou vektorů 2048 bit a Intel s AMD proti tomu nemají vůbec nic?
To mám věřit tomu že v AMD jsou diletanti co používají vědomě horší 256 bit AVX a budou přihlížet jak jim ARM obsadí trh se super počítači? Tam musí být nějaký háček.
Tak trh se superpočítači už obsazený je (mimochodem u GPU výpočetních serverů je to AMD EPYC, protože jde přímo na něj připojit efektivně spoustu karet GPU, které sdílí jednu root doménu, díky I/O čipletu spojujícího všechny bloky jader CPU). Co se týče výkonu samotného CPU, AMD nemůže přijít s nějakou novou instrukční sadou, pokud nemá zajištěno, že ji implementuje i Intel. Ta potřeba tady není taková, jako byla v době přechodu na 64 bitů. AMD by jen plýtvalo křemíkem, který by pak zas odstranilo (jako např. 3DNow!).
A proč tedy ARMv9 cpe do CPU šílenou šířku 2048 bit vektorů, když je lepší použít 100x výkonější GPU? To mi hlava nebere. Co to v tom ARMu hulí?
Protože GPU v ARMu je ořezaná - počítá s těsnou spoluprácí s hlavním procesorem (koneckonců jsou spolu na jednom křemíku). Kdežto svět PC je primárně svět samostatných komponent, z kterých skládáš celek (proto tam např. i HDD/SSD má v sobě celý počítač, jako CPU a RAM, komunikující po sběrnici s hlavním CPU). Specielně pro superpočítače (a cloud) je výhoda cpát věci do CPU ta, že uspat a probudit GPU je problém (zákazník nepotřebuje trvalý běh své VM - virtuálního stroje - ani za to není ochoten platit, ale rád by po spuštění pokračoval tam, kde skončil).
Aha, takže výpočet vektorů přes CPU může být rychlejší než přes GPU kvůli těm latencím. Jaká je vůbec latence při přístupu do GPU pro výpočty?
wiki pise:
V oboru informatiky je bfloat16 (brain floating point) označení konkrétního způsobu reprezentace čísel v počítači pomocí pohyblivé řádové čárky. Jedná se o formát založený na dvojkové soustavě, kde nejvyšší bit vyjadřuje znaménko, dalších 8 bitů vyjadřuje exponent a posledních 7 bitů vyjadřuje signifikant. Jedná se v podstatě o šestnáctibitovou variantu dvaatřicetibitového datového typu single definovaného standardem IEEE 754. Údajně se to hodí pro strojové učení. nepřijde mi to jako něco co bych potřeboval.
Ty ne, no. Proč mě to nepřekvapuje. A není to údajně, skutečně se to používá na strojové učení (Google, NVidia, Intel, ARM). Wiki píše:
https://en.wikipedia.org/wiki/Bfloat16_floating-point_format
Jedním z důvodů, proč se cpe strojové učení z GPU do CPU, je, že uspat a pak úspěšně probudit VM s GPU je problém (pronajímaná kapacita v cloudu).
Tak ještě jednou mně ani baprosté většině lidí to k ničemu není. Pro ty co to tak nustně potřebují tak logicky, pokud je to 16 bitová obdoba 32bitového datového typu tak co mi brání na stejnou funkci použít ten stávající 32bitový typ??
...v podstatě nic ...jen je to principiálně pomalejší (samozřejmě ale záleží na konkrétní implementaci)
Ano, polovina křemíku je nevyužitá (nevyužíváš větší přesnost). Takže jen leží ladem (místo toho, abys ji použil na 2x tolik výpočetních jednotek pro dvojnásobný výkon). V dnešní době honby za výkonem a efektivitou se nevyplatí takhle mrhat (i efektivita je dnes součástí výkonu - jaký výkon zvládneš uchladit).
Co jsem se díval, ta Bfloat16 má brutálně zkrouhlou mantisu z 23 bitů na 7 bitů, kdežto exponent zůstává stejný. Což znamená že řádově to bude mít dynamický rozsah jako 32 bit float, akorát ztratíš přesnost.
https://en.wikipedia.org/wiki/Bfloat16_floating-point_format
Taky si myslím, že násobení jakožto o dost pracnější operace než sčítání, tím pádem bude víc jak 3x rychlejší.
Takže mi vychází že Bfloat16 umožní zpracovat 2x víc dat při 3x menší spotřebě. Teda alespoň na Atmelu při SW emlulaci přes integer by to tak bylo.
Ne každý procesor pracuje jako Atmel (ještě navíc při SW emulaci) ;-) Zhruba to vychází tak, že polovina bitů jede 2x rycheji než plný počet (a naopak). Tohle se používalo už dávno, např. GeForce FX 5xxx (první řada GPU od NVidia s Pixel Shader 2.0) mělo v 16bit výpočtech nad pixely taky dvojnásobnou rychlost proti 32bit přesnosti (ale degradovalo to grafické efekty, jako lesk, kde se používá exponent).
Přece float je integer s exponentem. Ten algoritmus emulace je identický jako při HW jednotce FPU. V podstatě porovnáš exponenty, uděláš bitový posuv dle rozdílu exp a pak normálně provedeš výpočet dvou integerů. Akorát ten SW algoritmus trvá několik cyklů a zabíráš tím několik registrů, zatímco HW jednotka to provede všechno sama a rychleji.
Šlo mi o to, že násobení 23 bitového int a 7 bitového intu je dost podstatný rozdíl.
Akorát nevím jak by vypadala úprava té HW FPU jednotky aby to mělo 2x větší propustnost při Bfloat16. Minimálně musí zdvojit výpočet exponentu a výpočet mantisy musí umět místo 23 bit 2x 7 bit. Já bych to řešil tak že bych pro 8. bit zahodil carry bit ze 7. a tím pádem by od 8. bitu byl sčítán druhý Bfloat16.
HW jednotky jedou maximálně rychle, tj. single cycle. Proto tam nemůže být nic jako carry bit (kdy následující operace závisí na předchozí). Složitost výpočtu určuje počet tranzistrorů, který to potřebuje. Návrháři maj různé nástroje, jak to optimalizovat, aby pro více typů výpočtů bylo co nejvíce tranzistroů sdílených. Ještě jednou, tohle není Atmel.
EDIT: Zajímavost, single cycle FPU byla už v Rendition Vérité - GPU z roku 1996, konkurující výkonově v Quake 1 s o pár měsíců později vydané 3Dfx Voodoo 1. Zabírala tehdy půlku čipu.
NE!
Výpočty trvají několik cyklů, typicky dělení je rekurzivní záležitost kterou nemůžeš provést HW single cycle ani kdyby ses rozkrájel. Respektive ukaž mi procák který to dovede, to jsem fakt zvědav. Ani násobení intu neumí AFAIK moderní Ryzeny na jeden takt, natož dělení floatu.
A pleteš se, zákony binární logiky platí jak pro 8-bit Atmel, tak i pro 64 bit Ryzen úplně stejně. Akorát šířka je větší. Je vidět že tomu moc nerozumíš.
ANO!
Rychlé dělení se dělá tak, že se nejprv vypočte 1/x, a pak použije násobení. A tím single cycle se myslí, že udělá tolik výpočtů, kolik má jádro procesoru frekvenci * počet FPU jednotek (pokud se podaří je efektivně využít). Výpočet sice trvá víc cyklů (a má to vliv na latenci - za jak dlouho se dočkáš výsledku), ale ty jsou schované v pipeliningu (výpočet rozdělený na více cyklů ma každou část v jiné stage v pipeline, a zatímco pozdější stage dokončuje výpočet, předchozé stage už začala počítat další intrukci).
A nepletu se. Sice zákony binární logiky platí, ale ne posloupnost instrukcí, jak to řešit. Už jen to, že mluvíš o posloupnosti instrukcí, znamená, že to děláš softwarově (což sám i explicitně uvádíš). Ale tady se bavíme o HW řešení.
1/x u integeru bude vždy 0 (aneb int neumí desetiná čísla). Takovou kravinu sis teď vymyslel ne? Navíc principielně u floatu je 1/x v podstatě taky dělení, takže bys z jednoho dělení udělal dělení + násobení. To je pěkná blbost cos napsal.
Eh, bavíme se o floatech. A kdyby ses dovzdělal, tak bys věděl, že procesory tohle dnes počítají polynomiálně (nepotřebují přesný výsledek, jen aproximaci pokrývající počet míst datového typu).
EDIT: Na tvoji "obhajobu" musím říct, že tohle ten tvůj Atmel nemá. Proto to neznáš ;-)
Neutíkej ke goniometrickým funkcím.
Bavíme se o tom tvém nesmyslu že CPU provádí dělení floatu pomocí 1/x a násobením. Chápeš vůbec že Float je reprezentován exponentem a integerem, což znamená že při dělení dvou Floatů dochází k dělení dvou intů? AMD Ryzen používá Radix děličku:
https://en.wikipedia.org/wiki/Division_algorithm#SRT_division
BTW: takhle nějak SW emuluje dělení i ten Atmel, který HW děličku nemá:
http://www.rjhcoding.com/avr-asm-8bit-division.php
Uz AltiVec na PowerPC G4 (~rok 2000) standardne pocital delenie nad vektorom iba s ciastocnou presnostou (tusim 24 z 32 bitov?). Ak to cloveku nestacilo, zavolal si doplnkovu instrukciu, ktora dopocitala zvysok.
To je velmi chytré. Dělení probíhá od největšího čísla po nejmenší, takže stačí přerušit tu smyčku v algoritmu dřív. Ten PowerPC nebyl asi vůbec špatnej ve své době.
Zakladna vyhoda asi bude v tom, ze SVE2 bude na ARM9 povinne (fyzicka sirka vektora bude volitelna) a Neon ostane len pre spatnu kompatibilitu s ARMv8. Cakal by som, ze sa podpora Neon-u casom zahodi.
Oproti tomu AVX-512 je z programatorskeho hladiska obrovska obluda a zdaleka nie kazdy procesor podporuje uplne vsetko "AVX-512 consists of multiple extensions that may be implemented independently. This policy is a departure from the historical requirement of implementing the entire instruction block. Only the core extension AVX-512F (AVX-512 Foundation) is required by all AVX-512 implementations. " [wikipedia].
Tu ide Intel tam, kde ARM uz bol a zistili, ze to k nicomu dobremu nevedie. Jadro je sice velmi flexibilne, ale na druhej strane je za trest na to pisat software a jednotlive jadra su potom vzajomne binarne nekompatibilne. Toto tu bolo v 90tkach a po roku 2000, ked sa ARMkove jadro dalo vyskladat prakticky akokolvek, ako clovek chcel. S podporou Java bytecode, bez nej, s FP, bez FP, s Neonom, bez Neonu, s tym a onym. Potom existovali veci ako ARMv4-TDMJF... a tie jadra boli v podstate binarne nekompatibilne. Alebo musel clovek software pisat s tym, ze prakticky ktorukolvek cast bude nutne niekde softwareovo emulovat. Potom sa presadili Cortexy, kde clovek z principu vie, co dostane a prakticky jedina vec, ktora je flexibilna (aj to len na Cortex-M) je FPU. Mensie procesory ju bud nemaju vobec, alebo ju maju orezanu na single precision. Tam ale to FPU casto ani nie je treba, takze sa setri kremik na spravnom mieste.
Ale ten ARMv4 se používal do nějakých mikrokontrolérů jako jsou ty Atmely, tam bych tu segmentaci chápal protože ne každá pračka potřebuje výkonou FPU pro zpracování 4K videa, že. Proto mne udivuje že každý mobil v kapse bude podporovat instrukce pro superpočítače a stolní pecko nic.
Takže ty SVE2 mám chápat tak, že Intelu a AMD v oblasti vektorů začíná ujíždět vlak?
Je málo pravděpodobné, že by běžné ARMy (v mobilech a levnějších laptopech) podporovaly plnou šířku SVE2. Vektorové výpočty dnes většinou mnohem efektivněji řeší (GP)GPU. A ani na CPU není větší šířka registrů vždy nějakou extra velkou výhodou, většina procesorů s AVX-512 má jen jednu FMA jednotku. Oproti AVX2 přináší navíc maskování a lepší gather/scatter, to může výrazněji pomoci.
Co to je to maskování? Něco jako u Atmelu když chci vyseparovat z bajtu horní nible tak nastavím 11110000 a provedu logický AND?
Ne, AVX-512 má maskovací registry, které určují, na kterých částech vektoru se provede operace. Trochu to je podobné podmíněným instrukcím na ARM32, jdou tak eliminovat některé ify.
Počky, ale maskovací registy dělají to samé co já u Atmega takto udělám ručně, ne? Prostě provedou operaci jen tam kde mají nastavenou "1" a ignorují "0". Je to tak ne?
Jenže ten logický bit se aplikuje na celou jednu komponentu vektoru (klidně 4-8 bajtů) a funguje pro všechny operace (včetně FMA, odmocnin, exponentů...).
To je logické. Takže pro Bfloat16, kterých se vleze do 512 bit 32x tam mají 32 bit masku? A pro 64bit double 8 bit masku?
Tem mobil v kapse bude mít výkon jen jako PC, ne jako superpočítač. Ale instrukční sada je vymyšlená tak, aby program mohl použít maximální délku bitů - na mobilu výpočet pojede výkonem, jako když bys na PC emuloval více bitů sekvencí operací na CPU s méně bity. Výhoda ale je, že nemusíš psát jiný kód pro mobil a jiný pro superpočítač. To dává např. více času na optimalizace kódu knihoven.
Pomaleji to chápu, ale v podstatě mobil s SVE2 bude umět rozběhat SW napsaný pro super počítač? Něco jako kdyby Atomy v NASu uměli rozběhat SW s AVX512? Nebo spíš AVX2048?
Já furt hledám ten zádrhel, přece AMD nemůže zaostávat za mobilama.
Ten zádrhel, je, že tohle vůbec není o AMD. AMD nemůže přidat lepší instrukce, pokud se nedohodne s Intelem, aby je ten přidal taky. Jinak to dopadne jako např. s 3DNow!, kde Intel místo toho později přišel s SSE, takže AMD musel implementovat i SSE, a tím pádem výrobci software neměli důvod dělat verzi i pro 3DNow!. AMD pak po letech tyhle instrukce z CPU vyhodilo.
Ptalo se AMD Intelu když zavedli rozšíření instrukční sady AMD64? Neptali, jenže to měli tenkrát v AMD koule. Lisa Su ani koule mít nemůže, tím se to vysvětluje. A Intelu upadly koule u desáté reinkarnace 14+++++nm procesu :D
AMD tehdy šlo o přežití x86, kterou Intel opouštěl. Dnes nabízí AMD rychlejší procesory než Intel a zároveň teží ze zavedeného ekosystému x86. Přidání dalších intrukcí znamená plýtvání křemíku, který jde použít na další obecná jádra. Viz např. jeho výkon v AVX2 (256bit) * větší počet jader > výkon v AVX512 * menší počet jader u Intelu (pokud to není speciální software na míru AVX512, ale speciální software tu vždy byly a budou - nejen pro AVX512, ale třeba i ARM).
Jenže dnes už jim o přežití nejde, prodá se vše co se vyrobí, takže na to kašlou. Podle tebe Zen 4 bude mít 128 bit vektory protože to podle tebe je výhodnější dát víc slabších jader? Nebo jenom omlouváš neschopnost AMD navrhnout pořádně širokou FPU?
Jako já fandím AMD ale zase nejsem magor abych neviděl že 8bit Atmel je o dost slabší než 64 bit Ryzen. Prostě víc je lepší a bude to platit i u vektorů. Proto asi ten ARM to tak brutálně předimenzoval. Intel by se na AVX2048 dostal svým tempem asi tak za 20 let.
AMD donedávna byl ten druhý a teprv teď designuje nové procesory z pozice prvního. Ale nějaký rok potrvá, než tyto budou v krámě. Proto kvůli konkurenceschopnosti nedával instrukce, které jsou náročné na křemík, a které *zatím* nebyly moc využívané. Koneckonců ani většina procesorů Intel nemá AVX512 (v některých budoucích dokonce defaultně vypnuté kvůli malým jádrům). Plus, jak tu někdo připomněl, je tam bordel i v extenzích pro AVX512 (každý CPU Intel podporuje jen něco).
Šířku víc než 512 bitů Intel (prozatím) mít nemůže, už AVX2 brutálně snižuje frekvence. Moc to topí i na 10 nm procesu.
Jakto že ten Japonskej super počítač zvládá 2048 bit SVE? Když Intel nezvládá ani 512 bit?
Ti Japonci mají SVE se šířkou 512 bitů. On by to Intel zvládnul, pokud nevadí příkon nad 1000 W.
Jo aha, fyzicky tam Japonci mají HW 512 bit jednotky, ale samotná intrukční sada toho Armu umí až 2048 bit. Už to začínám chápat.
Takže ten Arm se výkonově dotáhnul na AVX512, zajímavé. Tedy je to rychlejší jak 256 bit AVX na AMD Ryzenech nebo je to pořád pomalejší protože Arm?
Ano, fyzicky 512bit. Ale až za pár let třeba někdo udělá ještě rychlejší superpočítač, a bude tam mít třeba 1024bit jednotky, tak existující software a knihovny je budou moci využít bez přepisování.
Tak rychlý je to asi +/- stejně pro stejné bity a spotřebu, ale je to mnohem levnější. Protože procesory si vyrobíš sám sobě na míru, místo abys kupoval předražené kousky od Intelu (tím předražené myslím hlavně to, že do superpočítače chceš to nejvýkonnější, ale marže obecně je u nejvyšších modelů výrazně vyšší než ve zbytku nabídky).
Proč si nikdo z ČR nekoupí licenci a nerozjede prodej superpočítačového CPU na armu? Na tom by se dal vydělat balík ne?
To sice ano, ale máš velké vstupní náklady. Proto se větší věci dělají jinde, nebo potřebuješ zahraničního partnera. Jinak superpočítače si dělají subjekty pro sebe, ne pro někoho jiného. Nevím o tom, že by se nějaká firma živila procesory do superpočítačů (superpočítače jsou i o infrastruktuře okolo - jejich propojení). Byl tu startup Nuvia, ale ten teď koupil Qualcomm, aby se pohl jeho vývoj konkurence Apple M1 (tj. ARM CPU pro notebooky a slabší desktopy).
...video enkodéry a dekodéry bývají většinou implementovány alespoň částečně jako specializovaný blok CPU nebo GPU (tedy samozřejmě je lze obejít čistě SW, ale pak se vytrácí efektivita).
Podpora bfloat16 nemusí být nutně v CPU, ale u PC se většinou používá k akceleraci GPU (např. nVidia Ampere) nebo specializované obvody (např. Coral, Intel, Google, ...)
PS: podporu má i Intel Cooper Lake
Takže Intel umí bfloat16! To znamená že AMD to umí taky? Proč to tak zdůrazňují když to umí každý slušný procák? Marketing ala Intel?
AMD ho umí ve svým GPU. Kdo ví, jestli to po vzoru nových Intelů přidaj taky do CPU. Osobně si myslím, že pokud jde konkrétně o strojové učení (důvod, proč bfloat16 vznikl), tak tam je lepší GPU. Případně časem nějaká synergie, kdy jsou všechny (ko)procesory integrovány v jednom SoC a pracují současně nad stejnými daty sdílenými v L1 cache (jako např. v Apple M1). Pak není důvod duplikovat křemík v CPU, GPU, NPU a já nevím, kde ještě.
Sdílená L1 keš s GPU? Jsi si jistý?
Nás ve škole učili že L1 keš má Harvardskou architekturu paměti a dělí se na datovou a na instrukční. Tudíž sdílet střeba instrukční keš mezi CPU a GPU když obě mají úplně odlišné instrukce s různou délkou je IMHO divné.
Ano, jak správně vzpomínáš na školní léta, L1 cache je nejen instrukční, ale i datová. Sdílí se jen ta datová.
A dáš mi příklad CPU který sdílí datovou L1 cache s GPU? Rád se přiučím od profíka, ale nikdy jsem o tom nic neslyšel.
Už jsem dal: Apple M1. Jde i pokračování architektury HSA:
https://en.m.wikipedia.org/wiki/Heterogeneous_System_Architecture
Apple M1 je jako co za pomalou sračku? Já znám jenom M1 Abrams a z MotoGP Yamahu M1 :D
Aha, tak apple M1 dávají do notebooků jako hlavní CPU, zajímavé. Ale výkonově koukám nic moc: Ryzen 5950X má v R23 až 28000 bodů a arm M1 jen 7800 bodů.
https://diit.cz/clanek/jak-si-vede-apple-m1-v-cinebench-r23
Koukni se na počet jader (a malá/úsporná počítej jako 1/2 velkého). Pro vyšší modely, kde je potřeba i multithread výkon, Apple už chystá M1X s více jádry.
Vy ste posledný polrok žil v jaskyni, že ste nezachytili nástup Apple Silicon v podobe M1? Jedná sa o 4+4 BigLittle ARM SoC s vlasným GPU a AI akcelerátorom
https://en.wikipedia.org/wiki/Apple_M1
Že to nedosahuje výkon 5950X? To je jasné, veď to má v princípe výkonovo len 6 jadier (4 "plnohodnotné" a 4 zamerané na efektivitu), kdežto ten Ryzen ich má 16, navyše v každom spracováva 2 vlákna, čo v pre M1 neplatí.
M1 je ale občas výkonnejšie, napríklad pri práci s relatívne veľkou sadou multimédií. M1 je čo sa týka pomeru výkon/cena pre jednoduchší strih videa aktuálne neprekonateľné.
Už sú dávno preč časy, kedy boli CPU ARM nevýkonné. Vaše neustále nepresné porovnávanie vytrhnuté z kontextu len ukazuje, že v odbore sa vôbec neorientujete, resp. zameriavate sa len na úzku oblasť, ktorú potrebujete pre svoju prácu, resp. hobby. Skúste si nájsť chvíľku a prebehnúť si rôzne recenzie, testy a podobne čo sa týka posledných ARM CPU a uvidíte, že ak ich porovnávate z cenovým ekvivalentom x86 tak až na nejaké výnimky, ktoré sedia viac x86, je už ARM viac než rovnocenným súperom pre x86. Sám by som si Mac s M1 kúpil, ale viac by mi vyhovovalo 15-16" prevedenie, plus vzhľadom na to že neviem či budem mať vôbec nejakú video letnú sezónu, tak si ani neviem ospravedlniť kúpu
"že ak ich porovnávate z cenovým ekvivalentom x86" Hmm, a kde můžu najít cenové porovnání procesoru M1 s těmi x86?
Moderní řešení je maximální integrace, takže samostatně ten procesor nenajdeš (ani by nedával smysl). Můžeš porovnávat cenu výsledných zařízení (koneckonců to je to, co zákazníka - ne IT geeka - zajímá). Vtipné je, že některé zajímavé procesory a grafiky Intel a AMD do retailu taky nejdou, jsou jen pro OEM. Apple tedy v tomhle není žádná výjimka.
No-x psal že M1 je pomalej shit, takže jsem další články o Applu ani nečetl.
Ono ta M1 má jen 4 velké jádra? Já jsem myslel že 2x víc než Ryzen a stejně je to pomalejší.
To jako chceš říct že 16-jádrová M1 by byla rychlejší než Ryzen 5950X????????
Když to psal No-x, tak to bude asi pravda ;-) Předpokládám No-x žádného Maca M1 ani v ruce neměl, že to napsal jen tak od stolu. Neva, kdo bude chtít, tak jsou např. videa na YouTube, kde lidi ukazují svoje konkrétní zkušenosti. Neříkám, že M1 je nejlepší ve všem, každý má pro počítač jiné typy úloh, a ne každý procesor se hodí na všechny. Pokud ti jde o multi výkon, tak na ten bude nadcházející M1X (M1 s více jádry). Ten půjde do vyšších modelů Maců.
To ako fakt takto povrchne beriete hodnotenie noviniek? Podľa jednoho článku? A môžem poprosiť aj odkaz na ten konkrétny? Nemám pocit, že by som tu taký článok videl.
Neviem takto dopredu predikovať výkon eventuálneho Apple Silicon s 16 jadrami, či už výkonnými alebo kombinovanými (8+8, či 12+4), musíme si počkať. Pri paralelizme neplatí že ak pridám dvojnásobok jadier tak mám automaticky dvojnásobok výkonu, prinajlepšom to môže byť tých 100% ale kľudne aj 0, ak sa dostaneme pri danej úlohe na hranicu paralelizácie. Čiže treba si počkať až to začnú predávať a vzniknú nezávislé testy. Samozrejme ako tu píše aj Ladis, ARM nie je pre všetkých a na všetko, rovnako ako x86 (nemám pocit že by na tejto architektúre veľmi vznikali sieťové komponenty alebo mobily)
Jen některé loňské Xeony. Třeba Tiger lake to nemá (aspoň ne ten můj). Tohle je fakt spíš záležitost GPU a AI akcelerátorů. ARM to má v novějších specifikacích, ale zatím to je spíš hudba budoucnosti.
...takhle jednoduché to není.
AMD CPU nativní podporu zatím nemají, a GPU jen formou SW knihovny (tedy pokud je mi známo).
Intel má podporu jen v rámci mikroarchitektury Cooper Lake, tedy aktuální generaci Xeon - https://en.wikipedia.org/wiki/Cooper_Lake_(microarchitecture)
PS: jak jsem uváděl výše, bfloat16 lze výpočetně realizovat i v rámci float32 (podpora prakticky ve všech x86 CPU i GPU, a samozřejmě i dalších CPU na bázi jiné instrukční sady), jen to je principiálně pomalejší
Jde kolem a dává nejlepší informace :)
Hm, takže Intel Bfloat16 umí, ARM taky, takže zaostává jen AMD, to nezní moc dobře.
Tam jde asi o to, že se do vektorů vleze dvojnásobek čísel a výpočet se provede 2x rychleji než 32bit float. Něco jako u Atmelu když do 8bit registru načtu 2x 4bit nible.
Ano, teď konečně můžu navázat na jazyk tvého kmene (Atmel) :-) Podpora 16bit floatů v AMD GPU je už roky, šlo o reakci na podporu v procesorech v iPhone (protože AMD je zatím stále jediným dodavatelem dedikovaných GPU pro Macy). AMD to tehdy udělalo trikem, že - jak uvádíš na příkladu s 2x 4bit nibble do 8bit registru - jsi uložil 2 16bit floaty do jednoho 32bit float registru, ale AMD přidalo speciální instrukce, které to číslo chápaly jako 2 s menší přesností. Driver pak na tyhle instrukce přeložil práci s 16bit floaty, takže pro vývojáře to bylo dostupné i transparentně. Dalo by se tedy říci, že je to softwarová emulace (instrukce se emuluje posloupnosti více instrukcí), nicméně stále to běží v HW, ne na CPU (tj. neběží to softwarově v tomto smyslu, a je to taky násobně rychlejší než čistě na CPU). Podobně AMD udělalo emulaci 64bit floatů na nižších řadách GPU, když tehdy ty uměly jen 32bit floaty (myslím, že to emuloval posloupnosti hardwarových int instrukcí v GPU - furt násobně rychlejší, než celý kód pixel shaderu počítat na CPU - pro každý pixel). PS: Nevím, jestli 16bit floaty, o kterých mluvím, jsou kompatibilní se zde diskutovaným bfloat16 a jestli AMD nepřidalo ten bfloat16 formát později jako takový.
float16 NENÍ kompatibilní s Bfloat16:
https://en.wikipedia.org/wiki/Bfloat16_floating-point_format
Konečně příklad na Atmelu, tomu nemám problém porozumět :D
ARMv4 alebo v5 (oboje su pre-Cortexove, ale neviem, z ktoreho StromARM vychadzal) boli aj v HP/Compaq Ipaq-och a tam ta chybajuca podpora FP dost bolela. Nevedelo to prehrat ani mp3jku.
4k video sa nespracuvava na FPU. 4k video dost pravdepodobne neda FPU ani v x86 procesore chladenom tekutym dusikom.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.