Názory k článku
Google Chrome pro Apple M1
-
Na jednu stranu je to pozitívna na druhú stranu negatívna správa..
Negatívna: Obrovské množstvo softwaru bude na M1 rozbitého, bude potrebné vynaložiť zdroje aby sa vydali aj verzie pre Apple M1.
Nemyslím si že to môžu developeri ignorovať, vzhľadom k postaveniu Apple.
Pozitívna: Lepšia konkurencia, zároveň širšia podpora softwaru pre rôzne typy systémov. Možno rozhýbe konkurenciu.20. 11. 2020, 11:32 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatelObrovské množstvo softwaru bude na M1 rozbitého, bude potrebné vynaložiť zdroje aby sa vydali aj verzie pre Apple M1.
Řešení Applu je takové, že software zkompilovaný pro x86 architekturu se na pozadí překládá pro M1. Proč si myslíte, že tenhle překlad bude rozbitý? V minulosti použil Apple stejný postup při přechodu z platformy PowerPC na x86 a fungovalo to. -
Ten preklad funguje asi ako Wine... niektoré inštrukcie ktoré x86_64 má, nemá žiadnu korešpondujúcu inštrukciu v ARM/M1 a naopak, už aj keby sa tie inštrukcie skladaly na seba aby sa simulovala inštrukcia z inej platformy, tak to zbytočne výrazne spomalí software, a aj tak sa vyskytnú určité chyby (najmä u veľmi špecifických inštrukcií, akých je v x86_64 hneď niekoľko).
-
Nechci se Vas nejak dotknout, ale vite vubec neco o tom o cem pisete ?
Wine neni binarni translator, ale implementuje pouze API, jsou sice nejake pokusy spustit cross-platform nejake aplikace (x86 vec na ARM), ale to bud pouziva qemu, nebo to je nedodelany pokus.
Dynamicky binarni translator je neco uplne jineho, tam neexistuje ze by tam "byly urcite chyby". Ano, samozrejme se to u nejake hodne silene kombinace instrukci muze stat, ale 99.999% chyb Vam prekladany kod jednoduse neodpusti, protoze pak nefunguje. Binarky co lezou z prekladacu jsou celkem ruznorode a vyskytuji se v nich pomerne casto dost obskurni optimalizace.
Co je peklo pro tyto translatory je samomodifikujici se kod ci ruzne JIT prekladace.
-
Ani preklad inštrukcií nie je preklad binárny, istým spôsobom áno, ale tak i Wine potom, lebo akýkoľvek software sa dá prezentovať binárne... Takže to prirovnanie nie je až tak špatný... u bežných inštrukcií samozrejme tie chyby reálne nie sú, ale ja hovoril z teoretického hľadiska, problém však stále zostáva u šialených inštrukcií, a verte mi tam tie chyby buď sú, alebo sú tie inštrukcie prekladané takým spôsobom, že výkon ide fakt minimálne o polovicu dole. Samozrejme zaleží od "prekladača",...
21. 11. 2020, 18:29 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Nezobecňoval bych na základě jednoho programu, který se chová poměrně specificky.
-
No třeba k tomu dodat, že Chrome pro M1 bude pravděpodobně optimalizovaný na jeden konkrétní procesor, zatímco x86_64 musí fungovat na řadě architektur procesorů, a to X let zpětně, proto se pak propast mezi konkrétními x86 procesory a M1 může v testech rozevírat.
Proto ten rozdíl není tak bombastický, jak se na první pohled jeví. -
Nevýhoda by mohla být asi jen ta, že u x86_64 verze se bude jednat o generický target (v podstatě architektura stará 17+ let, kde generický kód může použít "až" SSE2) kdežto u M1 se targetuje přímo M1 CPU, takže všechny instrukce co má, může C++ compiler použít pro jakýkoliv kód. Toto se ale netýká JIT a všeho co je optimalizované pro novější CPU.
Jedna zajímavost AArch64 je, že má specializovanou instrukci pro JS konverzi double to int32, kterou V8 využívá pro M1 target. Těžko ale říct, jaký to má vliv na rychlost generického JS kódu.
-
Pretože x86_64 za tie roky pribudli voliteľné fičúry, ktoré binárka nebude použivať, ak chce byť maximálne kompatibilná. Pre príklady viď https://www.phoronix.com/scan.php?page=news_item&px=Linux-x86-64-Feature-Levels.
M1 podobne nie je pôvodný Aarch64, ale je to ARMv8.4‑A. Všetky binárky budú aspoň pre tento level, pretože všetci vedia, ze starší chip pre tento operačný systém po svete nekoluje.
-
O použití SIMD se rozhoduje dynamicky, prohlížeče nebo enkodéry využívají nejvyšší dostupnou sadu instrukcí, o podpoře různých AVX instrukcí se program dozví za běhu z CPUID a takto to už funguje drahně let. Jen hodně tupý vývojář by to tam dal natvrdo (a protože takových není málo, překladače/knihovny to raději řeší automaticky). Zrovna Chrome na všech OS ve verzi pro Intel využívá AVX-512, pokud je k dispozici. Na macOS ovšem intenzivně využívá Metal, pročež architektura CPU se projeví jen u JS.
-
O použití SIMD se typicky nerozhoduje dynamicky, ale při překladu. Dynamicky se to rozhoduje jen ve specializovaných SW, kde někdo ručně napsal více variant kódu pro různé architektury. Překladače normálně dělají autovektorizaci a cílová instrukční sada (SSE, AVX, AVX2, AVX-512...) se vybírá parametrem při překladu. Při konzervativním nastavení, což je typický případ, protože SW musí běžet i na starém HW, se používá jen SSE a ne AVX.
-
Tak konkrétne AVX-512 sa využíva veľmi málo, pretože je iba v Xeonoch, jednom modeli i3 a potom až v Tiger Lake. Na to, aby sa investovali človekohodiny do podpory v bežnom sw je to zatiaľ sakra málo.
No a tých rozdielov je tam viac, viď link. Intel mal svojho času ambíciu (=implementoval to do Clear Linux) mať tri rozlične optimalizované binárky pre každý dynamický objekt - pre generic x86_64, haswell a avx512 a o tom, ktorá sa natiahne, rozhodoval ld.so.
-
V případě macOS je garantované SSE4.2 (prakticky AVX2). I ve světě Windows má i ubohý Surface Go všechny SSE a na Chrome OS, jak jsem nedávno zjistil, také — včetně obskurních Celeronů ve strojích za pár dolarů. Knihovny se vždy podle CPUID větví na “má AVX” a “nemá AVX”, přičemž AVX se pak rozpadá na AVX, AVX2 a různé části AVX-512. To AVX-512 je vůbec pekárna, protože málo CPU má dvě FMA jednotky na jádro, takže AVX2 je v praxi stejně rychlé. A i AVX2 na běžném stroji nijak zvlášť neválí, protože cache. Možná proto Rosetta 2 AVX vůbec nepodporuje.
-
Podle tohoto vlákna je základní profil pro mac-os SSSE3:
Relevantní je ale jen to, jestli je to zaplé "by default" (teď to neověřím), protože jestli ne, tak je kód stejně zkompilovaný jen pro baseline (SSE2), pokud to někdo nezapne explicitně. Největší přínos má ale stejně až SSE4.1, a souhlasím s tím, že to má dneska 99+% x86 CPU.
-
Xcode nastavuje parametry podle nejnižší verze macOS, pro kterou se překládá, pokud to není nějaká předpotopní verze, tak už nejspíš pokrývá jen novější CPU. Pro max. fér testy by to asi chtělo benchmark přeložený s vyššími optimalizacemi, jenže tam je stejně takový rozptyl, že pár instrukcí se nijak výrazně neprojeví. Podle mě to nestojí za tu námahu.
-
Jakub Valenta (neregistrovaný)
Mě spíš přijde nesmysl porovnávat výkonnost procesoru na základě těchto testů. Zkusil jsem si tyhle testy pustit v chromiu v linuxu s procesorem 4750U a vyšlo mi podstatně nižší skóre než co je v článku, takže evidentně se to liší i mezi operačními systémy (předpokládám, že v testu použili windows). Jestli to správně chápu z popisu těch testů, tak tyhle benchmarky se pokouší testovat rychlost webových aplikací v prohlížeči z hlediska jak to vnímá uživatel. Otázka je co to vlastně znamená a jestli jsou ta čísla přenositelná mezi různými operačními systémy?
21. 11. 2020, 12:33 editováno autorem komentáře
-
někdo už ho zkusil a vypadá to více než zajímavě https://info.crunchydata.com/blog/postgresql-benchmarks-apple-arm-m1-macbook-pro-2020
