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