Názory k článku
Proč je procesor Apple M1 tak rychlý
-
https://otechnice.cz/spolecnost-hp-predstavila-novy-notebook-s-procesorem-arm/
Nebál bych se, že trh hozené rukavice nevyužije, zvlášť když mají podporu pro Arm i Windows 10.
-
BobTheBuilderStříbrný podporovatelJenže doba je jiná.
Kdejaký prográmek pro Windows ke stažení má 32 a 64bitovou verzi. Jestli udělat ARM verzi bude znamenat jen zaškrtnout option ve Visual Studiu, ke stažení začnou být 3 verze celkem běžně.
Navíc dnes je mnohem víc softwaru legálního, leckdy na předplatné.
Dnes to může projít - zvlášť, pokud bude rozumně fungovat emulace x86/x64. A zase Apple ukazuje, že to fungovat může docela dobře, i Microsoft už s tím má nějaké zkušenosti.
Ostatně, C# .exe obsahuje MIL (Microsoft Intermediate Language), tam nejspíš není třeba měnit prakticky nic. -
Porting je v úplně pohodě - problém má jen kód napsaný lidma, co neviděli nikdy nic jiného než 32-bit Windows. Důležitý kód už byl ale dávno přeportovaný na Linux, takže dostat ho na MacOS/AArch64 nebude žádný problém. Ono ten memory ordering v C++ má nějaký význam a AArch64 je konečně architektura, kde se špatná volba projeví :)
-
Tak jednoduchoučké příkládky, které si může ověřit každý, opravdu nejsou problém. Problém jsou velké systémy. Jako bonus věci psané v C občas používají různé triky kvůli výkonu nebo paměti. Ještě lepší bonus jsou knihovny dostupné jenom v binárkách.
Blábol? C má platformně závislé velikosti intů. Psát v Cčku platformně nezávislý kód není až taková bžunda. Použít někde špatný typedef je hrozně jednoduché. A dokud se ta platforma nepřepne, tak všechno funguje.
Přetečení intu je nedefinované chování. To jsou občas takové bugy, že by jeden lezl po zdi.
Co třeba takový midpoint? Jak těžké může být blbé půlení intervalu? https://www.youtube.com/watch?v=sBtAGxBh-XI&ab_channel=CppConSetkal jsem se třeba s tím, že bylo pro pořádné otestování kódu na 64b potřeba zaplnit spodní 2 giga virtuální paměti, aby se odhalila špatná práce s ukazateli. Převádění ukazatelů na inty a zpět se v Cčku občas dělá. A [u]intptr_t tu nebyly vždycky. Navíc jsou stále ještě jen volitelné.
-
Winapi má svoje typedefy, Posix má jiné svoje typedefy. Přenositelné knihovny díky tomu musí používat směs standardních a vlastních typedefů. Takže je v tom binec. Windows.h je navíc makrožumpa, kterou je záhodno držet odděleně od zbytku kódu. Winapi typedefy mají své kořeny v 16b dobách a díky tomu jsou v novém kódu občas dost neintuitivní.
-
OMG. Tady nejde o POSIX, jde o to, že aplikace napsaná pro Windows (pro ty pomalejší ještě jednou, KÓD PRO WINDOWS) se dá přeložit pro ARM64 jen změnou hodnoty přepínače architektury, pokud kód nepsalo prase.
U cross-platform kódu se musí řešit mismatch mezi Windows a jinými OS, ať už jsou posixové nebo ne, ale to zase nijak nesouvisí s architekturou. S ARM64 na Linuxu nebo macOS taky nejsou žádné zvláštní problémy.
-
O posix tu jde proto, že windows only, ale zároveň přenositelného kódu jsem zas tak moc nepotkal. Když už to není nepřenositelná prasárna, tak už autor zrovna řeší i přenositelnost mimo Windowsí svět.
Winapi typy jsou historický nekonzistentní artefakt, na který dle mých zkušeností kašle kdo může (prasata i neprasata).Schválně jsem si rozklikl msdn stránku s doporučeníma pro to, aby ta windowsí aplikace byla přenositelná i na ARM a není toho málo. Z toho plyne můj závěr, že kromě změny hodnoty toho přepínače bude třeba i zatraceně hodně testování a ladění.
-
Kdo prevadi pointery do intu je normalni prase. Nedokazu si predstavit proc by to nekdo delal, navic i pri kompilaci pro 32bit to nejspise vyhodi warning. Neco jineho je indexovani polozek v poli, ale cpat pointery (ktere navic mohou projit realokaci a je treba na to myslet) do intu, proboha proc ? A to jeste kdyz uz teda musis, tak prece muzes pouzit void* ne ?
-
Ono to někdy, velice výjimečně, smysl mít může, ale pak to musí dělat člověk, který tomu rozumí do nejmenšího detailu, aby to nezprasil. To není jen v C(++), i Go nebo C# to umí, a ano, přesuny instancí objektů (aktualizace hodnot ukazatelů) je jeden z častých problémů, a nejde jen o GC nebo realokaci.
-
Používá se to celkem často, když jde o maximální výkon. V zarovnaném pointeru je dost nevyužitého místa minimálně na pár bitů. Na některých platformách se tam toho vleze až překvapivě hodně.
Třeba implementace vyhledávacích stromů tam ukládají pomocná data pro vyvážení. Dát bool vedle pointerů může znamenat dalších 8B nebo víc na uzel stromu.
Všechny handly ve winapi jsou pokud vím takovéhle obohacené pointery. -
A co ti brani to hezky pekne usporadat do predem alokovaneho pole, kdyz chces maximalni vykon ? Mas to pekne v cache vedle sebe a jedes. Vlastne kdyz k tem pointerum pridas bool, tak z toho mas stejne index do pole + bool s pridanou prevodni gymnastikou (ok pokud potrebujes 56 bit index, tak to stejne moc jinak neudelas, ale takto definovana struktura vypada rozhodne lepe). Navic pokud neprogramujes primo pro OS, tak dostanes pointer zacinajici 0xFF a mas smulu. Nevim, jestli jsou zrovna handly ve WinApi dobry priklad, ale chapu, ze navrhnout rozsiritelny, zpetne kompatibilni system je docela slozite. Oni na to proste sli takto a proto spousta funkci konci na Ex a kazda druha struktura ma v sobe nejakou promennou, kam mas zapsat velikost cele struktury a kazda druha funkce konci na Ex -> to jsi usetril pamet, co :D
-
Hele, já dával příklady, kdy se to používá. Předem alokované pole má taky svoje zádrhele, hlavně při přidávání a odebírání prvků. Mimochodem ve chvíli kdy máš před sebou obrovskou hromadu legacy kódu, který má za sebou nějaký historický vývoj, tak máš kapku svázané ruce.
To, že kanonické pointery mají rozkopírované znaménko je úplně v pohodě. Máme přece aritmetický shift. -
Nedávno jsem měl takové nutkání a rozhodování bylo těžké. Potřeboval jsem s pointerem zaznamenat vlastnictví (1 bit). Nakonec rozhodovalo: Chci 100% přenositelný kód? Odpověď zněla "ANO". Takže tam přibyl jeden bool
Tak ono se to dá udělat i přenositelně, ale pokud někdo nepíše něco, kde je potřeba výkon, tak je to asi jedno. High-performance kód je napsaný jinak než kód, kde na výkonu vůbec nezáleží.
-
Ale jakou má toto spojitost s MacOS/AArch64? Aplikace pro MacOS už 64-bit jsou, takže v případě M1 se jedná jen o přechod na jinou architekturu - datové typy v takovém případě budou v C/C++ stejné. Vždyť i aplikace pro telefony jsou dneska 64-bit.
Porting z 32-bit na 64-bit je dávno vyřešený problém. I totální lama může použít UBSAN, který právě ten undefined behavior zjistí, takze když napíšu `a << b` a `b` bude větší/rovno než počet bitů v `a`, tak ten UBSAN to právě najde, signed integer overflow taky, atd... Porting 32-bit kódu na 64-bit dnes je mnohem jednodušší než kdy dřív.
-
Velikost intů a pointerů je jen jeden z mnoha rozdílů. Přechod z x86 na ARM je problém třeba i kvůli tomu, že každý přístup do paměti na x86 má automaticky odpovídající fency. Na ARMu to tak není. V low latency a gamedev světě se třeba hodně používají specializované datové struktury bez zámků. A tam přechod na ARM odhalí mračna bugů, které se na x86 nemají šanci projevit.
Pokud je možné použít asan, ubsan a podobné, tak je to fajn. Ale zrovna v tady zmiňovaném MSVC je jejich podpora zatím těžce experimentální.
-
Ondra Satai NekolaZlatý podporovatelJo, ti programatori, co to portuji, ti museji kricet nadsenim.
-
Můžete ho sledovat i jinak třeba přímo na medium.com, kde je politiky minimum.
-
Filip JirsákStříbrný podporovatelKdyž ono to spolu souvisí. Pravděpodobně si je vědom, že ty politické hodnoty, o kterých píše, jsou potřeba k tomu, aby vůbec mohl psát o nějakém Applu a aby vůbec mohl psát. Je smutné, že ty věci, o kterých píše, dávno nejsou samozřejmostí a je nutné o nich psát. Ale tím spíš je o nich potřeba psát.
-
Neni ;-)) ... konec koncu Apple nicky zadny CPU nemel, vzdy neco koupil a prodal k tomu licencovane casti ... casto mu je za penize jen odemkli ... a hned z toho udelal svuj skvely CPU ... i kdyz to bul treba jen mirne upraveny snapdragon ;-))
A pak mame ARM pro servery a ty jsou uplne, ale uplne nekde jinde ;-)) ... od firem o kterych na mobilech nikdy neuslyšíte ;-))
-
Po tom, co Apple předvedl s A12 a následovníky, nikdo soudný nečekal, že jejich CPU bude pomalý. Ano, je to low-end a má některá omezení, zrovna třeba RAM já osobně potřebuji u některých projektů mnohem více, ale to je zase hodně specifický požadavek malého procenta uživatelů. To chlazení je super, nejen že není nikdy slyšet větrák, ono se to ani nikde nezahřívá.
Docela jsem zvědavý, jak bude vypadat jablečný ARM v letošním novém Pro desktopu. -
Filip JirsákStříbrný podporovatel
Trochu se bojím. Naposledy se otázka „proč je procesor X tak rychlý“ používala v souvislosti s Pentiem, odpověď zněla „protože procesor 486 výsledky počítá, zatímco Pentium je odhaduje“ a byla to narážka na hardwarovou chybu v implementaci dělení v plovoucí řádové čárce v Pentiu (a vtip vycházel z toho, že Pentium byl první procesor z rodiny x86 se spekulativním prováděním kódu). Tak doufejme, že M1 bude představovat aspoň takový zlom, jako bylo první Pentium, ale že se to obejde bez těch chyb.
-
Filip JirsákStříbrný podporovatel
Pentium mělo branch prediction. Jinak by se ten vtip neříkal, tenkrát málokdo věděl, co bude v Pentiu Pro.
-
Filip JirsákStříbrný podporovatel
To byly dva různé vtipy. Oba narážely na chybu dělení v plovoucí řádové čárce (jak jsem psal), ale ten, který jsem zmiňoval já, narážel i na branch prediction, což byla ve světě x86 úplná novinka.
-
Filip JirsákStříbrný podporovatel
Prima, umíte rozkliknout odkaz v komentáři a opsat z něj první větu do svého komentáře.
-
Odkazovany clanek/blogpost je hodne tezke cist - a nejak vubec neodpovida na otazku kterou si klade - Proc to je rychly.
Protoze SoC, protoze jedna pamet ? Aaaale, jdete!
Ve svete X86 existuje nekolik generaci procesoru co jsou SoCy (od netbookovych single package Intely, pres APU, az po Epyc - vsechno co ma 1 cip + zdroje + ram + konektory bylo davno SoC).
Pamet do M1 opravdu integrovana neni a fundamentalne jina taky ne - a to ani kdyby ji udelali ve stylu HBM, bych nerekl ze pamet je integrovana. Je to proste RAM. Pro SOC nemusite pajet RAM na pouzdro procesoru. Ale co chcete od cloveka, co prebira jen marketingove zvasty a rozdil pajen na desce / pajen na pouzdru procesoru nevidi?
Jestli se integraci pameti mysli spolecny pametovy prostor CPU a GPU (a akceleratoru) - ten se davno nachazi na cipech od AMD i NVIDIE a neni to zadna prelomova technologie.
Takze nakonec se potvrzuje ze autor je jen kecalek, ale zadne informace o M1 neprinasi - to si budem muset pockat az Apple vyda nejaky oficialni whitepaper o technologiich, ktere delaj ten "vykon".
-
BobTheBuilderStříbrný podporovatel
Co je na něm těžké číst?
Jak dalece odpovídá na otázku (proč jeM1 tak rychlý) je jiná věc. Rozhodně některé důvody uvádí, třeba omezení architektury x86 při OoO provádění instrukcí. -
Myslim ze problem bude opacny, tento pan spada podobne jako Mara do kategorie co tomu sami nerozumi a presto se to snazi dale vysvetlovat - jsou to jen takovy tlachaci / popularizatori / influenceri, cilici na jednoduse ovlivnitelne lidi.
Ocekaval jsem poctivejsi nahled do fungovani - napr. tak jak trapi pan Christopher Domas ty x86 od ringu 3 po ring -4
https://twitter.com/xoreaxeaxeax -
Vždyť v tom článku nic není. Psal to očividně fanda, který je nadšený, což je pěkné, ale nekritický a povrchní, což už tak hezké není. Spousta informací je nepřesných a neúplných.
Nejpřevratnější na M1 je přechod Applu na jinou architekturu. To neznamená, že M1 sám není zajímavý počin, naopak, ale M1 je rychlý díky tomu, že si ho Apple připravil na míru tomu, jak chce, aby jeho produkty uživatelé používali. Jakmile se od toho odkloní (a třeba přijdou o akceleraci), výrazně zaostává.
-
Přijde mi, že jste si vybral jednu věc co je tam napsaná, tu jste si ani nepřečetl celou, a to rozporujete. Pokud je jedna věc podle Vás nepravdivá, znamená to, že je to celé pochybné, dále to číst nebudete a hotovo.
Očekávat, že Apple bude někde oficiálně roztrubovat proč je jeho technologie "tak rychlá" by bylo jakési "s**** do vlastního písečku", takže pokud nebude pro to potřebné připravit patenty, tak to dělat nebude. Pro Apple je dostatečné, že je to v testech velmi výkoné a k tomu nějaký ten marketing... nepotřebuje popisovat proč. Stačí když se toho dost prodá, a to se daří...
-
Nase testy dopadli zatim na M1 smisene - jsou veci ktere jsou rychlejsi (protoze akceleratory, protoze docasny boost), a pak kdyz od toho chcete vypocetne narocnejsi praci (napr. video denoise), tak to je zas nasobne pomalejsi.
A znat podstatu fungovani od vyrobce by bylo rozhodne lepsi, nez spolehat na odhady podle chovani.
-
Oni to sice neroztrubují, ale sem tam něco utrousí v rozhovorech. Že pevná délka instrukce značně usnadňuje dekódování je fakt. Tak tam nacpali víc jednotek, protože souběžné dekódování bez souběžného vykonání by nebylo to pravé. Ta "unifikovaná" paměť se projeví až v součinnosti s GPU. Kdyby nejvýkonnější Tiger Lake měl stejně výkonnou grafiku jako M1 a měl k dispozici stejně rychlé paměti a disk, tak výsledný počítač by se dostal na úroveň nových MacBooků (sice s o dost větším příkonem, protože slabší IPC musí dohnat frekvencí, ale hrubý výkon by dohnal) včetně třeba akcelerátorů pro kódování videa (Intel QuickSync je sice pomalejší než T2, ale aspoň to už není řádový rozdíl). Ale koho zajímá x86. Qualcomm teď koupil několik exjablečných CPU návrhářů, tak třeba taky časem předvede něco na úrovni.
-
Sveho case se me snazil Apple presvedcit ze PowerPC G3 je super vykonna architektura, ja si rikal huste, oni prodavaji IBM POWER ... pak ale pockaty, to nema na chlazeni turbinu ... aha to je dokruplney RS/6000 ... tedy takovby mega celeron s pidi vykonem ... co nemel ani na tehdejsi AMD Athlon, natoz pak na nasledujici 64bit generaci AMD ... dale se chlubili 64bit arch ... ame meli jen 32bit OS ... a vykon stal samozrejme za uplne h**** proto taky sly na x86 ze ;-))
Applu se neda verit v nicem, vse je jen markerting a klidne vylhany, nebot jejich sekta umlci kazdeho, kdo rekne pravdu, 1. kdo jej umlci je Apple, v USA usodi k smrti a v CR mu zakaze pristup ke vsemu co muze.
Dale v CR slusne podvadeli s DPH, ne ze bych to nechapal, ale vzpominate jak SW zdarma stal 60% ceny ... tak duvod nebyl SW, ale rozdilna DPH ... ktera byla na SW 5% ... ale to je de fakto v poradku ... kazdopande kdyz jsme chtel dat na G3 linux tak mi nehjaky mmlas od Applem tvdil, ze bnevim co je to RISC a ze tam zadny muj linux nnepojede, ze tam musi byt jejich OS a ne nejsky muj program ... no jsme se jako ROOT skutecnych UNIXu uz valel smichy ... cim agresivita Apple vuci me rostla ... chteli jsme je do clusteru na vypocty, pak jsme si pujcicili G3 z ucebny macu ... a po testech ve F90 jsme se smali a uz jem je nechteli ... ze srot za tolik penez kupovat nebudem.
Tak presne tak verim tvrzeni Apple ze maji zazracny CPU o vykonu, ktery svet nevidel
-
několik exaktních syntetických testů dělal třeba Daniel Lemire, https://lemire.me/blog/2021/01/06/memory-access-on-the-apple-m1-processor/, https://lemire.me/blog/2020/12/13/arm-macbook-vs-intel-macbook-a-simd-benchmark/
Zázrak to není, ale je to daleko před očekáváním a daleko před ostatními ARM procesory.
-
Ještě tohle: https://lemire.me/blog/2020/12/11/arm-macbook-vs-intel-macbook/
Zázrak asi nikdo nečekal, ale je to lepší, než všichni čekali. Ten SIMD mě na první pohled překvapil, ale když se člověk zamyslí, je to celkem logické, ten NEON provádí na jednom jádře čtyři float instrukce zároveň a AVX2 jen dvě. S tím, že Intel při AVX snižuje frekvenci, zvlášť starší CPU. Rád bych viděl porovnání s nejnovějším Intelem nebo AMD (Zen 3), ty by si Apple na chleba asi nenamazal.
