Parę dni temu pojawiły się raporty o pracach Microsoftu nad wsparciem dla aplikacji 64-bitowych w Windows 10 na ARM. ARM64 SDK rzeczywiście powstaje, ale - jak wyjaśnia główna menadżer Windows, Erin Chapple - nie rozwiąże to wszystkich problemów związanych z architekturą. Na czym polega specyfika ARM64, gdzie leżą trudności i kto będzie mógł z tego korzystać?
"Emulacja x64 obok x86 wymaga podwójnej pracy inżynieryjnej. Ponadto Windows wspiera warstwę abstrakcji Windows on Windows (WOW) tylko dla aplikacji 32-bitowych, a nie 64-bitowych. Musimy [dopiero] dodać obsługę 64-bitowej warstwy Windows on Windows" - mówi Erin Chapple w wywiadzie dla ZDNet. WOW jest używany przez Windows od dłuższego czasu, początkowo tłumacząc 16-bitowe API na 32-bitowe odpowiedniki (proces ten nosił miano thunkingu), a obecnie odpowiada za obsługę aplikacji 32-bitowych w 64-bitowych wersjach Windows. Wróćmy jednak do ARM. Istotne jest także to, że emulacja 64 bitów musi brać pod uwagę istnienie 16 rejestrów ogólnego zastosowania w architekturze procesora x64 (w x86 jest ich 8). Kryo 280 w Snapdragonie 835 ma owych rejestrów wprawdzie 31 i można je zaadresować w obu trybach (32-bitowym i 64-bitowym), ale warto też pamiętać o paru rejestrach, których potrzebuje sam emulator. Kluczowe z punktu widzenia wydajności jest zatem, by odpowiednio rozdysponowane były rejestry przeznaczone dla emulowanego kodu. Oczywiście łatwiejsze jest to w przypadku 32-bitowej emulacji.
Pewne schody zaczynają się, gdy zamiast ochrony rejestrów przez architekturę to sam emulator dokonuje alokacji na wysokim poziomie. Rośnie wtedy stopień skomplikowania emulacji, zwłaszcza gdy 32-bitowa warstwa emulacji jest już gotowa, a nowa warstwa 64-bitowa musi zostać napisana od zera. Chapple wyjaśnia, że mniej przewidywalna wydajność i dodatkowa praca mogą nie być dla wielu zbyt użyteczne. "Jest to technicznie możliwe, ale to kompromis między zasobami niezbędnymi do pracy a korzyściami dla użytkownika. Kiedy przyjrzeliśmy się naszej telemetrii dla najczęściej używanych aplikacji w Windows, zauważyliśmy, że większość z nich działa w wersjach x86. Wiele aplikacji ma również tylko wersje x86. Większość aplikacji tylko 64-bitowych to gry, które są poza targetowym klientem tego urządzenia. Wreszcie tylko 64-bitowe aplikacje chcą zwykle działać natywnie ze względu na wydajność. W związku z tym postanowiliśmy skoncentrować nasze inżynieryjne wysiłki na natywny ARM64 SDK, aby umożliwić programistom natywne pisanie aplikacji na te urządzenie".
Chapple odwołuje się też do kwestii wydajności: "Jeśli aplikacja korzysta z dysku twardego, grafiki lub sieci, wszystko to działa w jądrze i działa z natywną wydajnością. Jeśli aplikacja jest związana z procesorem, wymaga więcej czasu [na obliczenia] niż natywna, ponieważ musi zostać przetłumaczona. Różni się to w zależności od aplikacji. W naszych testach odkryliśmy, że większość aplikacji działających pod emulacją jest zgodna z oczekiwaniami użytkownika w zakresie czasu reakcji".
Prace nad ARM64 SDK nadal trwają. Microsoft nie określił jeszcze np., jakie wersje .NET będą wspierane. Oficjalnej zapowiedzi i prezentacji firma zamierza dokonać na majowej konferencji Microsoft Build 2018.
341f31d.png)