Miroslav Holec
Premium

Vývoj .NET aplikací na MacBooku s M1 (Apple Silicon)

Miroslav Holec   9. listopadu 2021

Článek se vztahuje k verzi produktu .NET 6

Tento článek je již zastaralý. Článek nemusí popisovat aktuální stav technologie, ideální řešení a můj současný pohled na dané téma.

Apple zhruba před rokem představil nový 13palcový MacBook Air a MacBook Pro. Oba stroje v sobě mají zcela nový čip z dílny Applu, označovaný jako M1. Ten veřejnost překvapil vysokou výkonností, která v podstatě překonala řadu strojů představených Applem v minulých letech. S letošním podzimem Apple představil další MacBooky s ještě výkonnějšími procesory M1 Pro a M1 Max. Zbývá otázka... dají se na tom vyvíjet .NET aplikace?

Pro úplný začátek je vhodné uvést, že Apple doposud osazoval své počítače procesory od společnosti Intel. To je nyní historie a od roku 2020 už vydává nová zařízení s vlastním ARMovým procesorem M1. Počítače s tímto čipem jsou velmi výkonné a energeticky úsporné. Z vlastní zkušenosti mohu potvrdit, že konfigurace MacBook Pro 13" M1 2020 (16 / 256 GB) je na tom výkonnostně o něco lépe než můj dosavadní MacBook Pro 15" 2018 (16 / 256 GB s i7 6jádrovým CPU). Pořizovací cena původního stroje byla přes 70 tisíc. Nový MacBook Pro si dnes pořídíte od 43 tisíc. Zcela stejný čip ale najdeme i v mnohem levnějším MacBook Air 13" 2020, který pořídíte od 24 tisíc. Svůj MB za 70 tisíc tedy mohu nahradit výkonnostně srovnatelným tenkým Airem za 24 tisíc. Nikdy neuslyším větrák a dva dny běžné práce nebudu potřebovat napájecí adaptér. Zní to neuvěřitelně.

macbook-m1-chip

Osobně bych nicméně volil spíše variantu MacBook Pro před variantou MacBook Air. V případě dlouhodobého vytížení CPU totiž MacBook Air sníží výkon za účelem uchlazení CPU. Verze Pro naproti tomu roztočí větráky a CPU uchladí bez ztráty výkonu. Nejlevnější Air (8/256) má k tomu deaktivováno jedno z osmi jader procesoru. MacBook Pro má oproti Airu TouchBar, který si můžete přizpůsobit a během vývoje na něm mít užitečné zkrátky třeba pro debugging. V neposlední řádě má řada Pro o něco málo lepší displej.

A co to programování v .NETu?

Vývojářské nástroje

Většina výrobců software již během roku vydala nové verze aplikací, které běží nativně na M1 čipu. Zbytek aplikací je schopen běžet s využitím tzv. Rosetta 2. Ta se stará o automatický překlad aplikací z varianty Intel na M1. Osobně jsem měl možnost vyzkoušet celý vývojářský stack a zaznamenal jsem jediný problém se softwarem Logi Options pro nastavení mé myši Logi MX Master 3 pro Mac. Konkrétně mi občas nefunguje vlastní zkratka pro jedno speciální tlačítko myši. Aplikace Logi Options je jedna z mála, které nebyly ještě vydány s nativní podporou pro M1. Ostatní výrobci reagují rychle a verzi pro M1 procesor většinou mají. Platí to i pro JetBrains Rider a DataGrip (obojí EAP) ale i pro menší nástroje jako Redis Desktop Manager, Homebrew a další. Zkrátka hladký přechod.

Zcela speciální kapitolou jsou však problematické aplikace od Microsoftu (což už snad nikoho nemůže překvapit). Microsoft své .NET vývojáře úspěšně ignoruje, takže pro M1 vydal v podstatě jen software, který je žádaný i jinými komunitami nebo uživateli. Příkladem je VS Code nebo kancelářský balík Office 2022. Nativní podpory M1 se dočkalo i prostředí Visual Studio for Mac 2022. Nástroje specifické pro .NET vývojáře kupodivu fungují díky Rosetta 2, takže se na jejich migraci pro M1 Microsoft úplně vykašlal. Běh pod Rosetta 2 je naštěstí bezproblémový. Je to utilita, která běží na pozadí a o které vůbec nevíte.

Dotnet Runtime & SDK

Největší problémy způsobuje samotný .NET (Core) runtime. Z mého zkoumání to vypadá tak, že aplikace postavené na .NET 5 i .NET 6 lze spustit v rámci SDK verze 6.0 a proces běží nativně nad M1. Starší verze nejsou podporovány. Instalátor mi je dokonce vůbec nenainstaloval (zkoušel jsem SDK 3.1.415 a 5.0.403). Podle původních zpráv byla v plánu nativní podpora pro .NET 6 a starší verze .NET Core 3.1 a .NET 5 měly běžet pod Rosetta 2. Jak je to ve skutečnosti se ukáže snad dnes, během konference dotnetconf. Každopádně aplikace, které jsem zmigroval na .NET 6 bez výjimky fungují korektně (14 menších aplikací).

Nakonec to tedy dopadlo celkem dobře. Ještě před releasem .NET 6 totiž fungoval jen běh aplikací na .NET 6 RC2, nefungoval EF Core 5 a vůbec žádné dotnet tools. Též nebyly funkční Blazor WASM aplikace. Je vidět, že roční release cyckle je skutečně nesmysl.

Je MacBook s M1 vhodný pro .NET vývojáře?

Vývojáři pracující s .NET 5 by měli do konce února přemigrovat na verzi .NET 6 kvůli ukončení technické podpory verze 5. Migrace z .NET 5 by neměla být složitá pro běžné MVC a Razor Pages aplikace. Též gRPC služby a REST API by mělo být možné migrovat hladce. Mnoho potenciálních breaking changes není ani v případě EF Core. Podpora .NET 5 je nicméně naprosto nevyzkoušená (objevila se až 8. listopadu) a tak bych osobně s MacBookem počítal zejména pro vývoj .NET 6 aplikací. Pro tyto scénáře lze MacBooky s M1 procesorem .NET vývojářům doporučit. Naopak potíže budou mít vývojáři, kteří jsou, jakkoliv zaháčkovaní na .NET Core 3.x nebo starších verzích.

Vhodné je před přechodem též zkontrolovat podporu oblíbených aplikací například na tomto webu nebo na tomto webu. Můžete eventuelně napsat mně a pokusím se poradit. V případě přechodu z jiného MacBooku si vývojář se vším hravě poradí. V případě přechodu z Windows bych byl opatrnější, protože změna operačního systému s sebou nese i změnu pracovních postupů. Prošel jsem si tím před 3 lety, a i když jsem si to za sebe užil, ne každý je otevřený hledání nových cestiček jak řešit různé zaběhnuté rutiny. Windows vývojářům bych s přechodem doporučil ještě chvíli počkat, dokud se nedořeší podpora pro starší verze frameworku přes emulátor Rosetta 2, nevyjde finální verze Rideru (aktuálně EAP) a zkrátka se více nerozplyne pach v zaprděném Microsoft ekosystému.

Postřehy z migrace (shrnutí)

Pro běžný vývoj aplikací (menší solutions) bych si vystačil s 8 GB paměti. V určitých chvílích však dochází k zbytečnému swapování na disk, což se odrazí na životnosti SSD. Pro jistotu (NB kupuji na několik let dopředu) a kvůli streamování a práci s videem jsem si raději pořídil 16 GB verzi. Větrák jsem slyšel jen při delším renderování videa.

Rychlost spouštění aplikací je oproti předchozímu MB vyšší. Práce v Rideru je absolutně plynulá. Myslím, že takhle plynule mi nejel ani Notepad na Windowsech. Velmi rychlá je práce v Chrome a vykreslování stránek. Vlastně všechno je svižnější, a to ani nemusím mít připojené napájení. Tady cítím velký krok dopředu.

Rychlost kompilace .NET aplikací je srovnatelná. U malinkých demo aplikací dokonce pomalejší, u větších to vychází stejně. To jediné mě překvapilo. Čili práce v IDE je rychlejší, ale spuštění aplikace už je stejné. Práce v browseru je zase rychlejší, což bude určitě znát u větších JS aplikací.

Menší 13" displej je oproti 15" nezvyk. Prostor mi stačí, na většinu úkonů je ideální. Je dobré si rozmyslet, zda je pro vývojáře důležitá velikost displeje nebo hmotnost zařízení. Já většinu času dockuji a pracuji na externím monitoru, takže volím přenositelnost na cestách. Spíše, než na displeji mi přijde málo místa na TouchBaru. Každopádně kdybych měl sedět celé dny u notebooku a programovat přímo na něm, zvážil bych větší displej.

Klávesnice už není typu butterfly, která mi subjektivně vyhovovala více. Byla však poruchová, což mohu potvrdit ze své zkušenosti (po roce jsem nechal měnit v servisu). Nový typ klávesnice je na druhou stranu stejný jako externí hardwarová, takže po celou dobu práce používám jeden typ.

Wi-Fi 6 mi nepřijde rychlejší, a naopak na některých Wi-Fi pozoruji výrazné zpomalení. Nevím, čím to je, ale tohle se moc nepovedlo. Problém jsem zaznamenal u dvou zařízení s M1 - čili buď problém SW nebo routeru?

K MacBooku lze připojit jen jeden externí monitor do 6K rozlišení. To může vývojářům na Windows připadat málo, jelikož neznají systém ploch na platformě macOS. Z mé zkušenosti připojení externího displeje funguje bez problémů. Vyzkoušenou mám také externí kameru Logi c920 a funkční je též připojení externího fotoaparátu přes AverMedia Live Gamer. Zda budou nějaké potíže s projekty u zákazníků se teprve ukáže.

Výdrž baterie je úžasná. 15 až 20 hodin bez kabelu.

Tichost. Ani u streamování videa se mi větráky zatím nespustily. U původního notebooku se ozvaly větráky už při otevírání větších solutions. To osobně ocením při tvorbě videa, streamů i školení ve firmách. Kromě toho se počítač nezahřívá, a tudíž není problém mít hliníkové tělo MacBooku delší dobu na kolenou.

Závěr

Vzhledem k tomu, že většinu aplikací mám zmigrovanou na .NET 6 anebo pracuji s aplikacemi, které běží nad .NET 5 (což se nyní ukazuje funkční), neotálím s přechodem na M1 čip. Během posledních dnů jsem přestěhoval všech obsah na nový MacBook a aktuálně již frčím na nové verzi.

Aktualizace 9.11. / 15 h. - stav SDKs a runtimes

Po dalším pátrání jsem zjistil, že instalace jednotlivých verzí dotnetu na MacBooku s M1 čipem je od 8. listopadu poněkud odlišná. Verze podporující nativně M1 čip se instalují do původního prostoru: /usr/local/share/dotnet. Verze starší, tedy v mém případě SDK 3.1.415 a 5.0.403 se instalují do podsložky x64. Součástí je i muxer, tedy na jedné mašině se nachází 2 verze nástroje dotnet.

instalovana-sdk-na-macbook

Při práci v terminálu se automaticky vezme nativní dotnet nástroj a ten očividně umí zajistit, že se aplikace napsané ve verzi .NET Core 3.x nebo .NET 5.x zkompilují a úspěšně spustí. Domnívám se, že si automaticky umí očuchat požadovaný TFM a podle toho pravděpodobně delegují volbu hosta na druhý hostfxr. Takže z terminálu lze spustit aplikace napsané ve starších verzích frameworku.

V případě IDE je však situace jiná. Rider i Visual Studio Code něco dělají jinak a aplikaci se spustit nepodaří. Konkrétně se nepodaří najít jiný framework než ten verze 6.0. Působí to, jako když IDE rovnou úkolují hostfxr verze 6.0 a ten tudíž neumí zpětně najít starší verze. Každopádně Rider umí zvolit si muxer pro každou solution zvlášť, takže pro starší projekty si jednoduše nalinkuji dotnet ze složky x64.

rider-version-dotnet