S Macem M1 jsem přešel na ARMový procesor u macOS v roce 2021 a byl to snadný přechod. Nyní jsem však začal také více experimentovat s ARMem pod Windows. Trvalo to sice sedm let od ohlášení podpory Windows na ARMu, ale člověk i dnes musí počítat s různými nástrahami a být trochu nadšenec. Přitom to není přímo chyba Microsoftu. V lecčem je zas situace podobná procesorovým válkám, které probíhaly v polovině 90. let.

ARMový Windows jsem zkoušel už na MacBooku Air M1 před rokem, když jsem rozběhal Windows 10 on ARM Insider Preview v opensource virtualizaci/emulátoru UTM (QEMU). Byl to takový zajímavý hybrid desítek a jedenáctek – oproti standardním Windows 10 on ARM už konečně uměl emulovat 64bitové programy pro x86 (x86-64). Původně totiž Microsoft implementoval pouze emulaci pro 32bitové programy. Podobně jako když alternativní platformy na Windows NT měly v základu v 90. letech vždy jen emulaci 16bitových programů pro x86.

Tak jako kdysi, i tentokrát se to ukázalo jako nedostatečné, protože není potřeba spouštět jen starší aplikace, ale také ty nové, kde vývojáři nemají vůli portovat pro naprosto minoritní alternativní platformu (z pohledu ekosystému Windows). Některé velké programy už podporu pro ARM dostaly (webové prohlížeče snad všechny hlavní), ale když bych si měl vsadit na to, zda nějaký náhodný program má i variantu Windows/ARM, určitě bych sázel proti. Ostatně ani takový WinRAR, který potkáte na každém druhém PC, dodnes ARMovou verzi nemá (7zip naštěstí ano). Když už pak něco má (například konečně MS Office), tak vám pak stejně v pozadí nechá běžet nějaké podpůrné procesy, které v Microsoftu nepřekompilovali z x86.

Tohle je velký rozdíl oproti Applu – ten řekl, že celý systém přejde na jiný procesor a všichni se s tím nějak poperte. Microsoft nic takového neudělal a ani nemůže, protože ve světě PC/Windows není jeden dominantní hráč, který může udělat tak zásadní změnu (se vším dobrým i špatným, co to znamená). Windows 11 už nicméně emulují x86 programy pro 32 i 64 bitů a jejich reálná použitelnost se tím výrazně zvedla. Otázkou je nyní už pouze rychlost.

Rychlost špatně predikovatelná

Většina programů, kvůli kterým občas potřebuji Windows, běží krásně. Dost často to nejsou programy, které by potřebovaly výkon čehokoli – staré diagnostiky k autům, konverzní programy pro komunikaci se starými počítači, čtení jejich formátů disket atd. Tohle všechno běží překvapivě bez problému. Tedy úplně stejně, jako bych je pouštěl na počítači s procesorem od Intelu/AMD. Problém zůstává tam, kde instalátor staršího programu potřebuje nahrát do systému i nějaký ovladač – pak to selže na špatné verzi. Zlobí také některé moderní hry.

Jako test rychlosti jsem zkusil PCem, tedy kompletní emulátor devadesátkových PC včetně základních 3D akcelerátorů (S3, 3Dfx). Tam se ukázalo, že verze pro x86 běží v emulaci na Apple M1 asi o 40% hůř než na první generaci Intel Core i7 – cca 15 let starém procesoru. PCem samozřejmě můžu mít v rychlejší nativní verzi pro ARM pod macOS, takže to bylo spíš o zvědavosti (verze pod macOS ale zdaleka není tak dobrá).

Skutečně užitečnou činností, u které jsem sice neočekával výkonovou náročnost, ale na macOS nejde, je otevírání OLE objektů v dokumentech MS Office. OLE je systémovou komponentou Windows od dob 3.x, která neexistuje nikde jinde. Office je dnes možná jediný program (když nepočítám ActiveX), který ji používá. Můžete to znát jako ikonku souboru uvnitř dokumentu, na kterou můžete poklikat a otevře se jiný program. Pokud někdo vloží jiný dokument do dokumentu uvnitř Office (klidně Excel, anebo PDF do Wordu), funguje to kvůli návaznosti na OLE pouze v desktopovém Officu pod Windows. Ikonku souboru sice v dokumentu uvidíte i v ostatních verzích (webová, Mac…), ale soubor nepůjde otevřít, ani snadno extrahovat.

Nainstaloval jsem tedy do Windows 11 on ARM desktopový Office. Měl jsem licenci na 2016, která je jen x86-64, tak jsem s ní na test začal. K tomu jsem nainstaloval nejnovější Adobe Reader, který je pro otevírání embedovaných PDF nezbytný, byť je to ten nejneohrabanější prohlížeč ze všech. Adobe dostálo své pověsti a do dneška verzi pro Windows/ARM nemá.

Otevřel jsem některý z Excelů, se kterými pracuji, a zjistil jsem, že to nepůjde. Tedy ono to funguje – vložené soubory jsou vidět a jdou otevřít. Jenže Excel při každé změně zobrazení (scroll event), anebo výběru jiné buňky má prostoje 10-30 sekund, než opět začne reagovat. Při mé prchlivosti by tedy hrozilo, že počítač při takové reakční době prohodím oknem.

Uznávám, že jde o hrozné zvětstvo, kdy Excelový soubor má stovky megabajtů a v něm jsou stovky vložených PDF (například s výkresy každého kabelu uvnitř zařízení, a to od všech subdodavatelů). Jenže můj názor na to, že tohle není efektivní způsob řešení, je mi k ničemu, když dokument není primárně určen mně a nemám žádné právo někomu kecat do toho, jak ho dělá. PowerPointy s vloženými soubory chodí kolikrát i od subdodavatelů z Taiwanu, které můj názor zajímá nejspíš ještě o něco méně. Musím se tedy přizpůsobit.

Limitem je evidentně výkon jednoho jádra v kombinaci s emulací. Jakkoli emulace v mnoha situacích působí velmi svižně – například 3D x86 hry v Unity běží bez viditelného propadu výkonu – tady jde evidentně o hromadu systémových volání, kdy se akce přehazuje z jedné strany na druhou. Když si vezmu, že můj Apple M1 je vlastně poměrně výkonný v porovnání s tím, co lze najít ve standardních Windowsích ARMových zařízeních s procesory od Qualcommu, nedivil bych se, kdyby tam byla reakční doba místy až v minutách.

Nakonec jsem zjistil, že mám ještě volná nějaká zařízení ve svém Office 365 a nainstaloval novější Office z něj. Tím jsem dostal nativní ARMovou verzi (byť instalátor byl jen x86) a reakce v podobných dokumentech jsou nyní půl sekundy až sekunda na každou změnu zobrazení a buňky. Není to plynulé, ale použitelné už ano. Práce s těmito dokumenty není plynulá ani na moderních x86, takže jsem s tím v pohodě.

Kamarád vědec při testování programovacího jazyka Julia (dnes se používá často místo MATLABu) udělal takový malý benchmark, který kreslí několik animací fraktálů (Juliovy množiny). Je to vytvořeno z úlohy, kterou si připravil pro výuku studentů a já mu jen pomáhal otestovat prostředí programovacího jazyka na různých platformách, aby ho pak nezaskočilo, když mu tam přijdou studenti s macOS, anebo Windows.

Ten benchmark je nicméně skvělý pro porovnání výkonu. Pracuje vícevláknově, takže umí podle nastavení utilizovat všechna jádra procesoru, a zatěžuje především jednotky pro matematiku s plovoucí řádovou čárkou. V grafu níže můžete vidět výsledky různých systémů a u každého ještě několik variant podle počtu výpočetních vláken (1T, 4T…), které byly v testu povoleny.

Zajímavé je, že emulovaný x86 kód v Julii pod macOS běžel na Apple M1 stejně rychle jako na 8. generaci mobilní Core i5. To je mnohem lepší výsledek, než bych čekal. Je to jen 20-30 % výkonu dolů proti vykonávání nativního kódu.

Naopak mezi výsledky ThinkPad T480 a emulovaného x86 pod macOS jsou vidět výsledky emulovaného x86 kódu pod Windows 11 on ARM. Ty jsou vyloženě tragické (7-8x pomalejší než nativně) a počítač je pak horší než 13 let starý desktop s AMD. Nepříjemné ovšem je, že zatímco na macOS existuje vývojové prostředí Julia pro ARM i x86, v případě Windows je na webu nabízena pouze verze pro x86. Kdo tedy má ARMový notebook s Windows, ten tady úplně jasně narazí na nekomfortní důsledky své volby.

Windows za to nemůže

Je dobré dodat, že to není ani tak přímo chyba Microsoftu. Jejich emulátor musí fungovat na generických ARMech, včetně především toho od Qualcommu. ARMová architektura používá něco, čemu se říká weak memory model, zatímco x86 má strong memory model. Tím se definuje, co je zaručeno ohledně pořadí zápisů a čtení do paměti jedním procesorovým jádrem, když se na to díváte procesem běžícím na jiném procesorovém jádře (důvodem problémů jsou vnitřní cache jader a schopnost procesorů měnit pořadí instrukcí při vykonávání).

V architektuře x86 mají jádra mezi sebou komplikovanou komunikaci navíc, kterou si mohou předávat informaci o pořadí přístupů do paměti, ale u ARMu to tak není. Při emulaci kódu pro x86 to vytváří dodatečný problém, který je nutné řešit vkládáním speciální instrukce, která vyčistí instrukční frontu a zapíše cache do paměti. Tím se zajistí správnost vykonávání, ale je to za cenu velké ztráty výkonu.

Nabízí se tedy otázka, proč se to pod macOS neděje. Odpověď je jednoduchá – Apple dělá vertikální integraci. Má podchycený vývoj jak operačního systému, tak procesoru, na kterém běží. Čistě pro potřeby rychlé emulace x86 tedy do procesoru přidal schopnost fungovat podobně jako x86, byť je to za cenu, že nemůže tuto emulaci plně provozovat na ARMových procesorech jiných výrobců. Jeho emulátor Rosetta existuje i pro Linux (kvůli Dockerovým kontejnerům), takže je možné ho vyzkoušet na jiných procesorech. On tam opravdu běží, ale stabilně se to týká jen programů, které pracují v jednom vlákně a nenaráží tam na omezení memory modelu.

Útěk od PC k Macu

Do MacBooku Air M1 mě nakonec dotlačila PC víc než Apple. Vadily mi problémy v UI u Windows 11 (až nyní konečně jde nastavit taskbar, aby zobrazoval jednotlivá okna s popisky, ale jinak prakticky každá přepsaná GUI komponenta/aplikace je blbější a pomalejší) a narůstající potíže s PC platformou. Zvyšující se spotřeba a snižující se výdrž na baterii byla problematická zejména u Intelu. AMD je dlouhodobě úspornější, ale zas dlouho nemělo Thunderbolt a mělo výrazně omezený výkon při běhu z baterie.

Hlavní problém ale provází aktuálně většinu PC s Intelem i AMD. Microsoft si vynutil režim connected stand-by, kdy se počítač v podstatě pořádně neuspí. Běžně dnes lidi popisují, jak večer uspaný plně nabitý notebook má ráno v baterce jen 40 %. Tohle je pro mě naprosto nepřípustné a je to obří průšvih, který se moc neřeší. Přitom o něm dnes každý ví.

Pro mě nikdy nebyl macOS úplně láskou na první pohled. Nedá se však hardwaru (MacBook Air M1) upřít, že funguje fantasticky. Tohle evidentně vidí více lidí, protože různě Airy M1 vídám nezvykle často a překvapivě často u lidí, kteří je používají „navzdory macOS“.

Dost by mě zajímalo, jak se chovají ARMové notebooky s Qualcommem pro Windows. Něco mi napovídá, že problém s uspáváním bude možná dost podobný a je spojený především s operačním systémem.

Parallels Desktop jako nejlepší ARM

Microsoft kdysi uzavřel dohodu s Qualcommem, že Windows on ARM je možné instalovat přímo pouze na hardware s jeho procesory. Tato partnerská dohoda už měla údajně v této době vypršet, ale zda se tak stalo, netuším. Dosud se Windows přímo instalovaný na jiných procesorech neobjevil. Nejde jen o notebooky, ale také o minidesktopy, které Microsoft prodával jako vývojářský kit.

Qualcomm dlouho nenabídl dostatečný výkon a snažil se zaujmout hlavně funkcemi, které moc nikoho nezajímaly. Navíc se projevil standardní problém mnoha alternativních dodavatelů do světa Windows – tedy problémy s grafickými ovladači. Chyběla podpora OpenGL (Microsoft pak nabídl k doinstalování wrapper na jiné 3D API, aby problém částečně obešel), řada her/programů měla defekty ve vykreslování. Qualcomm se navíc nehrne do toho, že by vydával nějaké aktualizace, které problémy vyřeší. Problémy proto přetrvávají i po letech.

Ve výsledku je dnes nejspíš nejčastějším procesorem, na kterém běží ARMový Windows, ten od Applu. Sice zmíněná dohoda neumožňuje, aby na něm běžel přímo (což Apple nijak netankuje), ale virtualizace se netýká. Virtualizační nástroj Parallels Desktop pod macOS je tedy legálním řešením, jak mít Windows na ARMu a netrápit se se slabým procesorem (nyní už lze použít i VMware Fusion). Ve výsledku pak i lidi přímo v Microsoftu raději vyvíjejí pro ARM na MacBooku s virtualizací než na vlastním vývojářském kitu.

Parallels Desktop je typický produkt pro Mac. Instalace je jednoduchá a automatizovaná. Zadá se pár údajů a program si stáhne Windows sám. Dokonce jej nakonfiguruje tak, aby jej propojil se složkami v macOS, takže dokumenty, plochu atd. vidíte v obou systémech stejně. Systém je navíc nakonfigurovaný, aby žral co nejméně výkonu a startoval rychle. Paradoxně pak výsledek působí lépe ve virtualizaci na starém M1 než na mém moderním výkonném desktopu s Core i7-13700K, víc RAM a SSD RAIDem.

Parallels si napsal ovladače pro Direct3D i OpenGL na svou virtuální grafiku a tu pak napojil na reálný hardware na hostitelské straně. Dají se sem tam najít nějaké problémy, ale pořád to jsou mnohem lepší ovladače než od Qualcommu.

Je tu vlastně je jen jedna nevýhoda – Apple M1 neumí „nested virtualization“. Pokud už Windows běží ve virtualizaci, sám virtualizaci uvnitř sebe přístupnou nemá – neběží tam tedy Linuxový subsystém, neběží tam Windows Sandbox, ani Dockerové kontejnery. Pro tato nasazení tedy nejde použít. Novější procesory Apple Silicon již podporu na hardwarové úrovni mají, ale Apple ji zatím nezpřístupnil programům.

Procesorové války

Téma snahy o zničení dominance x86 je moje oblíbené. Poslední dobou jsem se ve volném čase začetl do různých hádek na USENETových diskusních skupinách z poloviny 90. let. Zejména do bojů PowerPC vs. x86, kdy byla představa, že spojení IBM, Applu a Motoroly přinese „tak dobrý procesor, že do konce dekády už všichni přejdou na něj“ (skutečně to tak někteří viděli…). To se nestalo a je evidentní, že dnes alternativní platformy musí překonávat úplně stejné obtíže jako tehdy.

To téma je tak zajímavé, že se k němu v nějakém historickém článku brzy vrátím. Dokonce jsem si kvůli tomu u kamaráda domluvil Apple PowerMacintosh 7200 (75MHz PowerPC 601), abych měl možnost vyzkoušet, jaké to vlastně tehdy bylo na straně Maců (došlo k úspěšnému, byť ne úplně hladkému přechodu z Motorola 680×0 na PowerPC). Vedle toho mám navíc doma různé staré ne-PC/ne-x86 počítače, na kterých mi běží Windows NT, takže je s čím srovnávat ze všech stran.

Dodatek

Než něco většího sepíšu, udělal jsem si na X/Twitteru druhý profil, kde se věnuji jen a pouze tomu, co aktuálně řeším kolem starých počítačů. Už teď tam jsou první pokroky se síťováním klasického Maca a přidáním 3D akcelerátoru.

Píšu to sice v angličtině, abych přetáhl i nějaké z tisíců sledujících ze skomírajícího Tumblr, ale na tak krátkém textu s integrovaným překladačem uvnitř UI sociální to snad ničemu nevadí: https://twitter.com/retro_swarm

Pod čarou

Zajímalo by mě, jestli tu někdo z čtenářů používá zařízení s ARMem pod Windows, jak dlouho a jaké má zkušenosti.