Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Emulacja trybu użytkownika

Niedługo na rynku zagości Windows 8 w wersji na ARM. Postanowiłem więc swoje dzisiejsze rozmyślania pewnemu, dość abstrakcyjnemu tematowi – czy byłoby to technicznie możliwe, by system ten był w stanie uruchamiać aplikacje ze swojego biurkowego odpowiednika bez rekompilacji?

“HAHAHAHAAHAHAHAHAHAHAHAHAHAHAHA zmień dilera” – ile w tym prawdy?

Zacznijmy więc od teorii. Powszechnie wiadomo, że aplikacji skompilowanych dla jednej architektury procesora, nie da się uruchomić na innej, ponieważ ich kod binarny jest całkowicie inny. Posłużę się tutaj metaforą języków. Przyjmijmy więc, że każda narodowość to architektura procesora. Mieszkańcy tych różnych państw posługują się odmiennymi językami, które tylko oni rozumieją. W takiej sytuacji, by nawiązać kontakt z obcokrajowcem, potrzebujemy albo wspólnego języka (tzw. kod zarządzany) lub tłumacza, który zna oba (emulator). Pierwsza opcja zapewnia takie same zrozumienie komunikatu przez obie strony, zaś druga – powoduje opóźnienia i czasem też błędy.

Emulacja całej platformy sprzętowej jest jednak zbyt powolne i na dłuższą metę – bezsensowne. Kompletny system operacyjny pożera sporo zasobów i działa wolno, jednak kto powiedział, że nie można tego zrobić inaczej?

Kamień z Rosetty

Na ten pomysł wpadło Apple, dokonując w 2006 roku przejścia komputerów Macintosh z procesorów PowerPC na procesory Intel. Pierwsze wersje Mac OS X (aż do wersji 10.6) na procesory x86 zostały wyposażone w emulator o nazwie “Rosetta”, który pozwalał na uruchamianie aplikacji skompilowanych dla PPC z akceptowalną prędkością. Oczywiście, narzędzia wymagające dużej mocy nie były zbytnio użyteczne, ale Rosetta nie ma żadnego problemu z tymi mniej wymagającymi aplikacjami, jak np. Word. Jak widać, działa – i nawet sprawdza się w praktyce.

Darwine – czyli próba stworzenia portu WINE na Maka PPC

Na podobny sposób wpadli twórcy portu WINE na Mac OS X, zaczynając prace nad swoim portem w 2002 roku. Można się domyślić, że samo przekompilowanie na PowerPC w niczym by nie pomogło – moglibyśmy uruchamiać nieistniejące, Windowsowe aplikacje skompilowane pod PPC. Dlatego też postanowiono zintegrować emulator procesora x86 z WINE już na bardzo niskim poziomie – wymagało to sporej ingerencji w kod, ale mogło się udać. Projekt był już w całkiem obiecującej fazie, jednakże porzucenie PowerPC na rzecz procesorów Intela wystarczająco zniechęciło twórców, by stwierdzić, że to po prostu się nie opłaca.

qemu-i386 i smartfony z pasjansem

Użytkownicy Linuksa już od dawien dawna mogli uruchamiać aplikacje z x86 na innych architekturach, przy użyciu qemu-i386. Mimo, że skonfigurowanie go jest bolesne niczym wrzód na dupie oraz wymaga wszystkich plików z pełnoprawnej dystrybucji Linuksa na x86 (brak niskopoziomowej integracji), okazuje się nawet działać. W przeciwieństwie do pełnej emulacji platformy x86, tutaj podlegają temu jedynie aplikacje i wymagane biblioteki, więc aplikacje integrują się z systemem w całkiem natywny sposób. Nie straszne im też interfejsowanie z jądrem. Gdyby jednak emulacja ta była zintegrowana na niższym poziomie, prędkość aplikacji uruchamianych w ten sposób byłaby o wiele większa. jshafer817 z XDA Developers pokazał, że w ten sposób jest w stanie uruchomić na Androidowym smartfonie lub tablecie pasjansa z Windowsa przez WINE. Oczywiście jest to dość problematyczne rozwiązanie, tak więc obecnie to jedynie sztuka dla sztuki. Ale kto wie, w jakim kierunku to dalej pójdzie?

Port ReactOS’a z wbudowanym emulatorem x86 – to możliwe?

Jak już pokazałem wcześniej, niskopoziomowa integracja emulatora instrukcji x86 czyni cuda. Wróćmy więc do pytania ze wstępu, czy Windows 8 na ARM mógłby uruchamiać aplikacje z biurkowych komputerów, gdyby tylko Microsoft tego chciał? Odpowiedź na to pytanie najwidoczniej znają pewni zwolennicy ReactOS’a, którzy zaproponowali takie rozwiązanie w przypadku przyszłych portów na PowerPC, ARM i resztę dziwacznych platform. Z danych zdobytych przez użytkownika BrentNewland wskazują na to, że używając tej techniki, można uruchamiać aplikacje z x86 na innych platformach z przynajmniej 50% ich natywnej prędkości lub nawet więcej, gdyby przechwytywać również odwołania do bibliotek i emulować jedynie te, które nie są dostępne w systemie. Jak widać, to możliwe, lecz wymaga sporego nakładu pracy, na który twórcy tego systemu nie mogą sobie obecnie pozwolić, wciąż tkwiąc w fazie alfa. Bardziej zainteresowanych, odwołuję do wiki ReactOS’a, która powinna odpowiedzieć na Wasze wszystkie pytania.

Konkluzja

Wracając jednak do Windows 8. Microsoft w przeciwieństwie do fundacji ReactOS dysponuje odpowiednimi środkami, by urzeczywistnić tę koncepcję i pozwolić nam cieszyć się starymi Windowsowymi gierkami na naszych ARM’owych tabletach, których nie mamy. Niestety, obecnie zostaje nam jedynie narzekać na politykę tej firmy. Pocieszający jest jedynie fakt, że będziemy przynajmniej w stanie uruchamiać aplikacje z platformy .NET bez większych trudności, ponieważ to kod zarządzany. 

windows linux oprogramowanie

Komentarze

0 nowych
dragonn   11 #1 17.06.2012 17:39

Po części trzeba zrozumieć MS - o ile do aplikacji by się to nadawało, to do gier to pewnie już nie, jak nie było sprzęt ARM jeszcze trochę odbiega wydajnością od PC (Ghz w ARM nie równa się Ghz w PC), do tego dochodzi trudna sztuka emulacji grafiki. Później były by komentatorze typu - "nie kupujcie tego bo nawet CS na nim zamula". Do tego dochodzi kwestia przyzwyczajeń - co zrobi typowy użyszkodnik jak np. będzie chciał uruchomić GG - wejdź na ich stronę i pobierze program dla PC, zamiast użyć dedykowanego klienta.

  #2 17.06.2012 17:45

Wrzuciłeś arta z bloga techvortalu? :>

  #3 17.06.2012 19:29

"...że używając tej techniki, można uruchamiać aplikacje z x86 na innych platformach z przynajmniej 50% ich natywnej prędkości lub nawet więcej..."
"Niestety, obecnie zostaje nam jedynie narzekać na politykę tej firmy. Pocieszający jest jedynie fakt, że będziemy przynajmniej w stanie uruchamiać aplikacje z platformy .NET bez większych trudności, ponieważ to kod zarządzany."

No to na co chcesz narzekać, skoro kod zarządzalny czyli .NET i tak zapewnia większą wydajność niż emulacja? No bo .NET na pewno zapewnia większą wydajność niż 50% kody maszynowego w C++.

psmicz   2 #4 17.06.2012 19:33

Problem w tym, że nawet .NETa i przekompilowanych programów w innych językach nie będzie można uruchamiać, bo Microsoft tak zarządził. Windows na ARM to niby ten sam system, ale będzie można uruchamiać tylko aplikacje dla Metro UI zainstalowane z Windows Store. Tryb klasyczny zarezerwowany jest tylko dla Office'a i wbudowanych programów typu Explorer, Panel Sterowania.

W_tym_temaciE   5 #5 17.06.2012 19:34

@dragon
Na PC'tach GHZ'y także nie oznaczają wydajności.

  #6 17.06.2012 20:06

Oprócz chciejstwa polecam także zagadnienie o nazwie "Oszczędność energii". ARM ma być do urządzeń działających dość długo i ważących znacznie poniżej 1 kg. Ani emulacja, ani aplikacje WinAPI nie są skłonne do takich wyrzeczeń.

pisarzksiazkowicz   7 #7 17.06.2012 20:50

@dragonn,
Warstwa między jądrem emulowanym, a rzeczywistym, teoretycznie spokojnie mogłaby wykorzystywać fizyczne GPU. Owszem, ARM odbiega wydajnością od PC, ale nie jestem w stanie uwierzyć, że kilkurdzeniowa Tegra nie byłaby w stanie obsłużyć jakiejś prostej aplikacji z Windowsa, która działa płynnie chociażby na leciwym już Pentium III. Swoją drogą, Rosetta pozwalała na uruchamianie gier, które raczej nigdy nie zostałyby przekompilowane dla procesorów Intelowych, więc taki CS powinien na tablecie z Tegrą działać płynnie IMHO.

@psmicz,
O przekompilowanych aplikacjach wiedziałem, ale nie słyszałem o żadnych ograniczeniach w kwestii oprogramowania .NET. Dobrze wiedzieć, teraz całkowicie nie widzę sensu tego systemu na ARM.

dragonn   11 #8 17.06.2012 22:53

@W_tym_temaciE wiem, chodziło o samo porównanie że na przykład MS7272T 800Mhz ARM nie będzie się równał starem Duron 800Mhz. @pisarzksiazkowicz nie zapomni co wspomniałem o przyzwyczajeniach, sam widziałem ile raz na pulpicie Mac łądował instalator exe GG, czasami pobrany nawet kilka razy :|, nie doświadczony użytkownikom ta opcja mogła by przenieść więcej szkód niż korzyści.

pisarzksiazkowicz   7 #9 17.06.2012 23:32

@dragonn,
GG jest niewydajne i zasobożerne, ale raczej ruszy na kilkurdzeniowej Tegrze IMHO. Wiadomo, że klient dla Windows RT będzie w Metro na pełnym ekranie, co jest tragiczne.

dragonn   11 #10 18.06.2012 09:28

@pisarzksiazkowicz nie chodzi o to że ruszy, ale chodzi o spadek wydajności/pracy na batteri. I gg podałem jako przykład, nie jest to jedna aplikacja na której by się skończy, nie dziwimy by się jak by można u niektórych użytkownik znaleźć tablety wyposażone w 90% w programy x86, a później marudzenie że to wolno chodzi i słabo trzyma na baterii.

pisarzksiazkowicz   7 #11 18.06.2012 11:57

@dragonn,
Alternatywna rzeczywistość, gdzie na tablecie z ARM'em mamy aplikacje x86, również jest pełna aplikacji przekompilowanych z x86 na ARM. Co za problem, by strona GG wyczytywała to z user-agenta i oferowała wersję natywną?

dragonn   11 #12 18.06.2012 18:34

@pisarzksiazkowicz znając zapłon GG nie stanie to się prędzej niż w ciągu pół roku czy roku, a chodzi o sam przykład, ten sam problem dotyczy całej gamy innych aplikacji, a aplikacja natywna, nawet jeżeli tylko przekompilowana to już inna bajka.

  #13 20.06.2012 01:09

@pisarzksiążkowicz
Widzę że dyskusja już od dwóch dni martwa, ale mimo to pozwolę sobie na przytoczenie pewnego porównania. Niedawno Intel zaprezentował nowe procesory Atom dla smartfonów i tabletów. Są to jednostki jednordzeniowe, o taktowaniu 1GHz. Mimo tylko jednego rdzenia i niskiego taktowania okazało się, że nowy Atom jest i tak szybszy od czterordzeniowej Tegry3 z taktowaniem 1,5GHz. Ale na chwilę zostawmy Tegrę i wróćmy do rodziny procesorów Atom. Co prawda Windows Xp całkiem nieźle spisuje się na słabiutkich Atomach, nawet Windows7 jako tako daje radę, ale te systemy pracują na dwurdzeniowych modelach Atoma z taktowaniem co najmniej 1,5GHz. Licząc łopatologicznie daje to około trzykrotnie mocniejszy sprzęt. i to przy założeniu że notebookowy Atom różni się od tabletowego tylko liczbą rdzeni i taktowaniem, a Intel nie dokonał w wersji dla tabletów większych cięć (a raczej właśnie tak zrobił).
Wróćmy teraz do Tegry i ARMów. Można założyć, że spadek wydajności przetwarzania kodu w wyniku emulacji będzie wynosił mniej więcej 50% (osobiście nie liczyłbym na więcej niż 50%). Okazuje się więc, że aplikacja emulowana na czterrdzeniowej Tegrze3 będzie działać około sześciokrotnie wolniej, niż na platformie natywnej ajką jest Atom (a i tak jego użytkownicy narzekają na niską wydajność i twierdzą że nawet do pracy z prostymi aplikacjami jest powolny). A tkwi tu jeszcze jeden haczyk. Aplikacja będzie działać "tylko" sześć razy wolniej pod warunkiem, że zostanie odpowiednio zoptymalizowana. Pamiętajmy, że Tegra3 to procesor czterordzeniowy, więc by wykorzystać jego potencjał potrzeba obciążyć wszystkie rdzenie. A proste aplikacyjki zwykle nie pisze się tak, by rozkładały się na wiele wątków. pamiętając że notebookowy Atom ma dwa rdzenia, przy założeniu że nasza przykładowa aplikacyjka jest jednowątkowa, oznacza to, że na czterordzeniowej Tegrze3 taka aplikacja będzie działać aż 12x wolniej niż na już i tak powolnym dwurdzeniowym Atomie, gdzie też nie można odpalić wielu interesujących aplikacji desktopowych bez zarzynania procesora i przymulania.

Po co więc komuś taka emulacja? Jedyną aplikacją, którą można by jako tako sprawnie emulować na ARM (ale to i tak tylko przypuszczenie, nic pewnego) jest systemowy notatnik.
Więć po co komu taka emulacja?

pisarzksiazkowicz   7 #14 20.06.2012 16:25

Rosetta się sprawdziła, choć emulacja platformy PowerPC jest moim zdaniem bardziej wymagająca, niż x86 (przynajmniej nie widziałem sprzętu, na którym śmigałoby PearPC). Te obliczenia są, moim zdaniem, mocno przesadzone.

http://www.youtube.com/watch?v=bVYlrv0kbdA

To już działa - na Linuksie, rzecz jasna.

  #15 20.06.2012 16:58

Najśmieszniejsze jest to, że to właśnie Intel pragnie emulować ARM, żeby na Androidzie-x86 chodziły dobrze aplikacje natywne. Mają to robić podobno poprzez konwersje kodu binarnego czyli coś jak AOT.
Ale ja wam tego nie pisałem ;-).