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

Obrovské 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

To mate iste pravdu. Tento pripad s Chrome ale ukazuje zajimavou vec: program prekladany pres rosettu bude o polovinu pomalsi.

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í.

To je nesmysl, v čem by jako měla být na amd64 nevýhoda? Clang maximálně optimalizuje na obou architekturách. Nehledě na to, že prohlížeč jede vše výpočetně náročné přes Metal a rychlost procesoru se výrazně projeví nanejvýš u JS.

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.

To je polopravda. Základní profil (SSE2) nemá ani instrukce pro zaokrouhlování FP. Ono je velký rozdíl celý produkt zkompilovat s -msse2 vs -msse4.1, ani nemluvím o -mavx2. Dnešní překladače umí využít vektorové instrukce na různé věci, jako třeba inicializace struktur atd...

coz ale uzivatelum Apple@M1 "muze" byt jedno ;-)

Vypadá to, že M1 je lepší x86 processor než kdejaký x86 processor. Moje 4700U se teď krčí v koutě.

Skvělá vizitka pro Intel :)

Z obrazku s grafmi vyplyva ze x86 beziaci x86 kod je rychlejsi ako M1 beziaci x86 kod, takze asi nie. Alebo ste mysleli nieco ine?

Z obrázku vyplývá, že jeden z nejlepších mobilních x86 procesorů sotva dává M1, která ten samý kód emuluje z x86.

Neemuluje, teda poväčšinou.

Rosetta 2 je AOT a mám ľahké pochyby, žeby čas potrebný pre AOT bol započítaný do benchmarku. Pri aplikáciach používajúcich JIT (teda napr. JS engine v browseroch), kde už z princípu nevie AOT, robí fallback na emuláciu a tam výkon padá.

Ono je vcelku jedno jak to je implementované, protože původní kód pro tu architekturu napsán nebyl a tak si stále stojím za tím co jsem napsal :-)

Uz jste na tom zkusil postgresql?

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