Historia systemów operacyjnych o architekturze 64-bitowej sięga mianowicie początku lat 90. Już w 1993 roku firma Digital Equipment Corporation miała gotowy system (Digital Unix) dla maszyn opartych na 64-bitowych procesorach RISC-owych Alpha. W jej ślady bardzo szybko poszedł producent legendarnych stacji graficznych – Silicon Graphics – ze swoim Iriksem. Obecnie w pełni 64-bitowe systemy operacyjne, zarówno dla procesorów RISC-owych, jak i Intela Itanium, mają w swojej ofercie wszyscy szanujący się producenci serwerów uniksowych (HP, IBM, SCO itd.). Do grona platform programowych dla sprzętu 64-bitowego dołączył też szybko Linux, a ostatnio również Windows.
Nikogo nie powinno w związku z tym dziwić, że systemy 64-bitowe są instalowane na różnego typu serwerach od kilku ładnych lat i sprawdzają się tam zupełnie nieźle. Nas jednak bardziej interesuje kwestia wykorzystania możliwości Itanium 2 i rodziny Hammerów na naszych biurkach. Z tym zaś jest nieco gorzej – i to nie tylko z winy producentów procesorów, przekładających ciągle premiery nowych układów. Co więcej, na razie 64-bitowe stacje robocze (np. produkcji SGI) zostały, głównie z przyczyn ekonomicznych, w znacznym stopniu zastąpione maszynami wyposażonymi w 32-bitowe procesory Intela.
Komu to potrzebne?
Mechanizm rozwoju rynku komputerowego (i nie tylko zresztą) jest bardzo prosty. U jego podwalin leży zainteresowanie klientów konkretną technologią. Nie inaczej jest w przypadku 64-bitowych procesorów i systemów operacyjnych. Mówiąc prościej: na naszych biurkach nie zadomowią się procesory nowego typu, dopóki nie będziemy ich naprawdę potrzebowali. Kiedy zatem nadejdzie chwila, w której takie jednostki centralne będą niezbędne zwykłemu użytkownikowi peceta?
Jak można wywnioskować z artykułów opisujących architekturę 64-bitowych procesorów Intela i AMD (patrz:
CHIP 2/2003 s. 82 i CHIP 4/2002 s. 74
), największą korzyścią z ich stosowania jest możliwość adresowania o wiele większych niż obecnie obszarów pamięci operacyjnej. O ile w procesorach 32-bitowych granica możliwości to 4 GB RAM-u, o tyle dwa razy “szersza” szyna adresowa pozwala obsłużyć ponad 18 EB (eksabajtów, czyli miliardów gigabajtów) pamięci. I chyba przede wszystkim w tym fakcie należy upatrywać szans 64-bitowych jednostek centralnych – bo już teraz pecety z 512 MB czy 1 GB RAM-u nie należą wcale do rzadkości. Na podstawie obserwacji rynku można podejrzewać, że w ciągu 2-3 lat pamięci będą na tyle tanie, a apetyt aplikacji na nie tak duży, że wielu użytkowników pecetów zamarzy np. o 8 GB RAM-u na płycie głównej.
Nieco mniejsze znaczenie mogą mieć korzyści wynikające z szybszego przetwarzania instrukcji przez procesor na skutek większej długości akceptowanego przezeń słowa. Większa porcja danych pobieranych jednorazowo z pamięci oznacza bowiem mniejsze prawdopodobieństwo trafienia w pamięć podręczną procesora – zjawisko to może w niektórych przypadkach niwelować zyski wynikające z szybszego wykonywania rozkazów. Pamięci podręcznej procesorów nie można z kolei rozbudowywać w nieskończoność – jedynym rozwiązaniem problemu wydaje się lepsze niż dotychczas dopracowanie systemu predykcji poleceń procesorów AMD i Intela.
Na razie jednak jedynym sensownym zastosowaniem procesorów 64-bitowych (czyli takim, w którym ich przewaga nad jednostkami 32-bitowymi równoważy zwiększone koszty sprzętu i oprogramowania) są serwery hurtowni danych i wielkich serwisów internetowych. W przypadku tych ostatnich konieczne jest bowiem przetwarzanie ogromnych ilości informacji, i to przetwarzanie naprawdę szybkie – a takowe jest możliwe praktycznie tylko wtedy, gdy większość potrzebnych informacji znajduje się stale w pamięci operacyjnej serwera. Nic więc dziwnego, że na liście producentów oprogramowania przeznaczonego dla 64-bitowych wersji Windows znajdziemy głównie takie firmy, jak Oracle, SAP, IBM (DB2, Tivoli) itd. I tu docieramy do podstawowego czynnika powstrzymującego migrację ze stacji roboczych x86-32 na ich wersje 64-bitowe.
