Zamknij komunikat

Nowy Office 2013
Do góry Skomentuj

64 bity w Windows 10 na ARM to dużo bardziej ...

64 bity w Windows 10 na ARM to dużo bardziej skomplikowana sprawa

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ć?

Windows 10 na ARM. ARM64 SDK.

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

Krzysztof Sulikowski
9 kwietnia 2018
558
Odsłony
Krzysztof Sulikowski
9 kwietnia 2018
558
Odsłony



Komentarze

Nie napisano jeszcze ani jednego komentarza. Twój może być pierwszy.

Dodaj swój komentarz

Zasady publikacji komentarzyZasady publikacji komentarzy

Redakcja CentrumXP.pl nie odpowiada za treść komentarzy publikowanych na stronach Portalu
i zastrzega sobie prawo do usuwania wypowiedzi, które:

  • zawierają słowa wulgarne, obraźliwe, prowokujące i inne naruszające dobre obyczaje;
  • są jedynie próbami reklamowania stron internetowych (spamowanie poprzez umieszczanie linków);
  • przyczyniają się do złamania prawa bądź warunków licencyjnych oprogramowania (cracki, seriale, torrenty itp.);
  • zawierają dane osobowe, teleadresowe, adresy mailowe lub numery GG;
  • merytorycznie nie wnoszą nic do dyskusji lub nie mają związku z tematem komentowanego newsa, artykułu bądź pliku.