64 bity już za rogiem

Od 24 września każdy posiadacz 64-bitowego procesora może pobrać za darmo i przez rok testować wersję beta Windows XP Pro x64 Edition. Korzystając z tej możliwości, porównaliśmy pracę kilku aplikacji w środowisku 64- i 32-bitowym.

Od 24 września każdy posiadacz 64-bitowego procesora może pobrać za darmo i przez rok testować wersję beta Windows XP Pro x64 Edition. Korzystając z tej możliwości, porównaliśmy pracę kilku aplikacji w środowisku 64- i 32-bitowym.

Lepiej poinformowani powiedzą, że 64-bitowe systemy to nic szczególnego. Przecież tak Windows, jak i inne systemy operacyjne pracują w serwerach już od kilku lat. Pracują, ale na innych procesorach, nie w takiej architekturze oraz z odmiennymi kodami i strukturami poleceń. Taka kolej rzeczy wynika wprost z ograniczeń rozmiaru pamięci, narzuconych przez 32-bitową długość adresu. W ten sposób można obsłużyć tylko 4 GB RAM, które przestały wystarczać pamięciożernym urządzeniom serwerowym wcześniej niż w popularnych desktopach. Chodzi o następny etap, stosunkowo tanie procesory powszechnego użytku, które poradzą sobie równie dobrze ze starym, 32-bitowym, jak i nowym kodem w zwykłych komputerach. Takie same oczekiwania sformułowano pod adresem systemu operacyjnego. Powinien obsługiwać zarówno 64-, jak i 32-bitowe aplikacje, te drugie pod kontrolą WOW: pomostu między węższą a szerszą platformą. Wersje beta systemu są do pobrania ze strony http://www.microsoft.com/windowsxp/64bit/evaluation/upgrade.mspx .

AMD dyktuje

Do tej pory standardy procesorów ustalał Intel, ale w tej konkurencji po raz pierwszy w tak poważnej grze karty rozdaje AMD. Przewagę uzyskało dość chytrze, bo pokonało konkurenta jego bronią. Rozszerzyło intelowską architekturę o nowe możliwości w bardzo podobny sposób, jak uczynił to jej twórca, przechodząc swego czasu z 16 na 32 bity. Tymczasem intelowski procesor 64-bitowy o nazwie Itanium jest rasowym RISC, ma odmienną architekturę, która nagina się do pracy w trybie 32-bitowym, ale niekompatybilnym z dobrze znanym systemem wywodzącym się od procesora i386. Natomiast rozszerzenie wymyślone w AMD, zwane x86-64, a w terminologii Intela EM64T, naturalnie przełącza się ze starego trybu w nowy. Przewiduje się przedłużenie do 64 bitów długości niektórych rejestrów znanych z dotychczasowych modeli rodziny i dodanie nowych. Bez zmian zostaje segment do operacji zmiennoprzecinkowych, wymienny z 64-bitowymi MMX, a osiem 128-bitowych rejestrów multimedialnych pozostanie tej samej szerokości, ale ich liczba będzie podwojona.

Najwięcej miejsca przybyło w rejestrach ogólnego przeznaczenia. Dotychczasowe wydłużyły się do 64 bitów (nowa nomenklatura przewiduje literę R na oznaczenie tej długości), ale także do szesnastu powiększono ich liczbę. Zmieniła się organizacja stosu. W trybie 32-bitowym stos można było zapełniać dwu- i czterobajtowymi danymi, w nowym systemie dowolność się skończyła, porcja umieszczona na stosie musi mieć osiem bajtów. W celu zachowania kompatybilności do takiej samej długości przedłużono rejestr wskaźników, chociaż jego starsza część nie wskazuje niczego i jest trwale wyzerowana. Formalnie adresy są 64-bitowe, ale tylko około pięćdziesięciu linii adresowych wyprowadzono na zewnątrz, co i tak pokryje zapotrzebowanie na dłuższy czas.

Z produktów Intela tylko najnowsze modele z serii Xeon DP, wykonywane w technologii 90 nm, realizują 64-bitowe instrukcje. Pierwotne wersje nie obsługiwały EM64T i zapewne nie obeszło się bez przeróbek. Z wielu doniesień i testów wynika, że w konkurencji 64-bitowej od produktów Intela lepiej sobie radzą Hammery z AMD. Bliższy związek architektury procesora z jej programową implementacją może mieć istotny wpływ na ten wynik.

Dziwne ścieżki optymalizacji

Inną przyczyną różnych wyników pozornie jednakowych programowo konstrukcji mogą być problemy z optymalizacją kodu. Pozornie mniej poleceń powinno być wykonanych szybciej, ale często jest inaczej, zwłaszcza jeśli szczegółów rozwiązań sprzętowych nie da się do końca ukryć przed warstwą programową. Klasycznym przykładem takiej zależności jest procedura odwołująca się do dużej tablicy danych. Bardzo przyspieszymy jej wykonanie, dzieląc wędrówkę po tablicy na części, z których każda zmieści się w pamięci podręcznej procesora. W przeciwnym razie ta pamięć będzie bezustannie przeładowywana, co przedłuży wykonanie programu. Oczywiście sposób optymalizacji takiego fragmentu zadania powinien zależeć od wielkości pamięci podręcznej i trudno mówić o rozwiązaniu najlepszym w skali globalnej, bez względu na konkretne rozwiązanie sprzętowe.

Ciekawa jest lektura zaleceń optymalizacyjnych wydawanych przez producentów procesorów. Czasem w pozornie bardzo podobnych przypadkach zaleca się całkowicie odmienną strategię postępowania, np. banalne operacje zmiennoprzecinkowe. Zamiast prostszej sekwencji:

fld QWORD PTR [foo] ;

fimul DWORD PTR [bar] ;

fiadd DWORD PTR [baz] ;

zaleca się najpierw załadować stos, a potem wykonać działania:

fild DWORD PTR [bar] ;

fild DWORD PTR [baz] ;

fld QWORD PTR [foo] ;

fmulp st(2), st ;

faddp st(1), st ;

Ale w przypadku rejestrów ogólnego przeznaczenia obowiązuje zasada odwrotna. Zamiast załadowania rejestru i następnie wykonania operacji:

mov rbx, QWORD PTR [foo]

add rax, rbx

zaleca się dodanie bezpośrednio:

add rax, QWORD PTR [foo]

Takie zalecenia mają swoje przyczyny w szczegółach konstrukcyjnych procesora i w przypadku innego modelu mogą być akurat odwrotne. Tylko którą wersję ma wybrać autor kompilatora?

To był przykład problemu w asemblerze, ale podobne dylematy są też z programowaniem w językach wyższego poziomu. Weźmy za przykład banalne sumowanie:

double a[100], sum;

int i;

sum = 0.0f;

for (i = 0; i < 100; i++) {

sum += a[i];

}

Wydaje się, że nie można szybciej, a jednak... Przecież procesor można zmusić do pracy czteropotokowej, więc dajmy każdemu z nich zajęcie. Oto bardziej skomplikowana, ale szybsza wersja:

double a[100], sum, sum1, sum2, sum3, sum4, sum;

int i;

sum1 = sum2 = sum3 = sum4 = 0.0f;

for (i = 0; i < 100;) {

sum1 += a[i++];

sum2 += a[i++];

sum3 += a[i++];

sum4 += a[i++];

}

sum = (sum4 + sum3) + (sum1 + sum2);

Oczywiście w przypadku procesora z innymi cechami konstrukcyjnymi optymalny algorytm powinien mieć odmienny kształt. Mamy do czynienia z mało uniwersalnym kodem, który bez woli swego autora może preferować rozwiązania jednego producenta, a dyskryminować innego. W takich warunkach decydowanie na podstawie benchmarków o wyższości jednego modelu nad innym jest obarczone dużym ryzykiem. W procedurach tworzonych na bieżąco w większym stopniu uwzględnia się specyfikę procesora, który jest już gotowy, niż układu dopiero budowanego i prawdopodobnie wcześniejsze wprowadzenie AMD 64 jest przynajmniej w części przyczyną przewagi w benchmarkach, jaką uzyskują procesory tej firmy nad produktami Intela.

System nie może przeszkadzać

Rejestry x86-64

Rejestry x86-64

Największy zysk z 64-bitowej architektury dają operacje na liczbach całkowitych o takiej długości. Wykonanie na przykład mnożenia, które w nowej architekturze jest pojedynczą instrukcją, w komputerze 32-bitowym trzeba zastąpić trzynastoma poleceniami. Po drodze zastępowane są trzy rejestry, których funkcjonowanie wymagałoby jeszcze dodatkowych instrukcji. W 64 bitach kilkakrotnie skracają się obliczenia. Ale są też opóźnienia, spowodowane głównie wprowadzeniem ośmio- zamiast dwu- i czterobajtowej granulacji adresów na stosie.

Do testów wykorzystaliśmy procesor Athlon 64 z pojedynczym kontrolerem pamięci i mniejszej, 512-kilobajtowej pamięci drugiego poziomu. Oznaczony jako 3800+ rdzeń procesora taktowany był z częstotliwością 2,4 MHz. Obsługiwał dwa moduły pamięci po 512 MB PC3200 CL2. Chipset NVIDII - nForce3 - zamontowany był na płycie głównej Gigabyte'a.

Systemy 32- i 64-bitowe (wersja ewaluacyjna nr 1218) Windows XP Professional były zainstalowane na oddzielnych twardych dyskach, a do uruchomienia jednego z nich wykorzystywaliśmy funkcję wyboru napędu startowego w BIOS-ie. Krytyczny dla zainstalowania 64-bitowej wersji okazał się dostęp do sterowników. W przypadku ich braku warto skorzystać ze wskazówek zamieszczonych w Internecie. Wiele z nich jest na stronach http://www.planetamd64.com, http://www.64bit-world.com i w grupie dyskusyjnej http://microsoft.private.windowsserwer_64bit , dostępnej na serwerze privatenews.microsoft.com .

System operacyjny

System operacyjny

Próbowaliśmy uruchomić wiele aplikacji i stwierdziliśmy, że starsze wersje rozmaitych benchmarków mają mniej problemów pod kontrolą Windows x64 od nowszych. Nie było kłopotów z produktami Microsoftu czy Adobe. Duża część programów odmówiła pracy, ale jeśli już zostały uruchomione, to funkcjonowały w tempie podobnym, jak pod kontrolą systemu 32-bitowego. Większych spadków wydajności nie zanotowaliśmy, a z przyrostów warto wymienić dziesięcioprocentową poprawę pracy pamięci w teście PCMark 2002, ale niepotwierdzoną w innych testach. Utrzymanie tempa pracy starszych aplikacji pod kontrolą systemu 64-bitowego nie zasługuje na kpiny; nie było tak dobrze kilkanaście lat temu, podczas podobnego przejścia z 16 na 32 bity.

W porównaniu lepiej wypadły aplikacje 64-bitowe. Mieliśmy do dyspozycji kilkanaście z nich, w większości powtórnie skompilowanych ze środowiska 32- do 64-bitowego, w mniejszości specjalnie optymalizowanych pod kątem nowych procesorów. Porównanie wydajności zamieściliśmy w tabeli, warto zwrócić uwagę, że na przejściu do 64-bitowej platformy najbardziej skorzystały aplikacje intensywnie wykorzystujące obliczenia na liczbach całkowitych: kompresor gzip i algorytm szyfrowania RSA. Taki wynik jest w większym stopniu zasługą procesora niż systemu operacyjnego. To oczywiste, że dobry system nie powinien przeszkadzać procesorowi w wykazaniu walorów.


Zobacz również