Dlaczego 64-bity!?

Sporo czasu minęło od mojej ostatniej publikacji. Lato i jesień są dla mnie okresem bardzo intensywnej pracy zawodowej. Całkiem zwyczajnie, w nawale obowiązków służbowych i domowych, brakowało mi czasu i ochoty aby zasiąść za klawiaturą. Teraz mogę nadrobić redaktorskie zaległości. Zastanawiałem się na jaki temat tym razem napisać kilka(?) słów. Czy dokonałem trafnego wyboru? Z taką nadzieją pozdrawiam wszystkich Czytelników i wierzę, że i tym razem felieton się spodoba.

Wstęp

To bardzo dobre pytanie! A odpowiedź wcale nie jest łatwa i oczywista. Zanim spróbuję jej udzielić popatrzmy na fakty, które miały miejsce w niedalekiej przeszłości. Na początku 2003 roku, za sprawą IBM, pojawił się 64-bitowy PowerPC 970, natychmiast użyty w stacjach roboczych serii G5 firmy Apple, reklamowanych jako najszybsze komputery świata. Nieco później, tego samego roku pojawił się Opteron, pierwszy przedstawiciel CPU 64-bit wyprodukowany przez AMD i w zasadzie przeznaczony do pracy w serwerach. Jednak szybko okazało się, że nie ma sobie równych w osiąganiu maksymalnych FPS w grach komputerowych! Na rynku serwerów królowało w tym czasie 64-bit Italium 2. Jednocześnie Intel udowadniał, że stosowanie technologii 64-bit w zastosowaniach biurowo-domowych mija się z celem i nie będzie przedmiotem zainteresowania firmy. Jak się niebawem okazało, Opteron spuścił straszne lanie konkurentowi (cena, wydajność) i AMD zaczęła powoli dominować na rynku serwerów, a jedynym problemem zaczęły być możliwości produkcyjne, o wiele mniejsze od konkurencyjnego giganta. Natychmiast dała się zauważyć zmiana frontu Intel’a, który rozpoczął wprowadzanie technologii 64-bit do swoich flagowych produktów. Wszystko to jest opisane w moich poprzednich felietonach i nie widzę sensu aby się powtarzać. Pomińmy też milczeniem teorie spiskowe Intel-Microsoft, mające na celu opóźnienie wprowadzenia na rynek oprogramowania i technologii 64-bit, gdyż są to jedynie spekulacje, których nie sposób udowodnić. Ważne jest to, że wreszcie powstała wersja 64-bit OS, przeznaczona wyłącznie dla procesorów AMD. Oczywiście tylko w wersji beta, a docelowy Longhorn nie pojawi się przed 2006 r. Ale jednak kiedyś ujrzy światło dzienne i odpowiedź na tytułowe pytanie powinna być udzielona. Wprawdzie fakt, że Longhorn powstaje już sugeruje, że używanie 64-bit OS ma sens nie tylko do obsługi serwerów i specjalizowanych programów naukowych, ale również biurowo-domowych. Zwłaszcza tych multimedialnych, oczywiście z grami komputerowymi na czele. Jednak nie wyjaśnia kwestii podstawowej: dlaczego? Próbę odpowiedzi przedstawiam P.T. Czytelnikom, zaznaczając jednocześnie, że tak jak poprzednie moje felietony, jest ona kompilacją materiałów znalezionych w różnych artykułach publikowanych w sieci, a wiele zagadnień związanych z tematem znacznie upraszcza lub wręcz pomija. To pozwala (moim zdaniem) naświetlić całość zagadnienia i nie poświęcać zbyt wiele uwagi szczegółom. Kto jest ich ciekawy - niech użyje Google!

Architektura 64-bit

Intuicja podpowiada, że powinna być dwa razy lepsza (cokolwiek to znaczy) od architektury 32-bit. Kto chociaż trochę zna konstrukcję współczesnych CPU wie doskonale, że będąc one nominalnie procesorami 32-bit, zawierają w swojej strukturze rejestry 32, 64, 80 a nawet 128 bitowe. Jaka jest więc zasada klasyfikacji procesorów, która określa do jakiej grupy je zaliczamy? Przyjęto, że decyduje o tym rozmiar tzw. GPR (General Purpose Registers). Służą one głównie do przechowywania adresów. Tak na marginesie: w architekturze x86 jest ich 8, natomiast architektura PC oferuje ich 32. Wiadomo już co musi być koniecznie zmienione: rejestry GPR muszą mieć rozmiar 64-bit. Pozostałe, niezbędne zmiany są dość oczywiste: wszystkie rejestry ALU (Arithmetic Logic Unit), przetwarzające dane zawarte w innych rejestrach, muszą również przejść na rozmiar 64-bit. Co to oznacza w praktyce pokazuje poniższy rysunek, który przedstawia 2-bit ALU, pozwalające wybierać wartość na wyjściu R, w funkcji 2 bitów wejściowych "a" i "b" oraz kodu Op określającego wykonywaną operację: "0" aby wykonać logiczne AND (i), "1" aby wykonać logiczne OR (lub) i "2" aby wykonać logiczne dodawanie. Retenue entrante i Retenue sortante oznaczają, odpowiednio, wprowadzane i zapamiętane dane z innego ALU, oraz zapamiętane dane, wychodzące z aktualnie pracującego ALU, zależne od stanu bitów "a" i "b". Liczba niezbędnych bramek logicznych (czyli tranzystorów, które muszą zostać wytworzone w strukturze rdzenia CPU) ściśle wiąże się z rozmiarem bitowym operandów, na których wykonywane są działania. Jest to najbardziej kosztowny element zmiany architektury z 32-bit na 64-bit, jednocześnie "przy okazji" zwiększający ilość wydzielanego ciepła. W świetle powyższego jest chyba również oczywiste, że rozmiary wszystkich szyn transportujących dane też muszą ulec podwojeniu. Natomiast, być może ku zaskoczeniu wielu Czytelników, rozmiary wykonywanych instrukcji wcale nie muszą ulec zmianie!

Architektura 64-bit bez problemu może pracować, wykorzystując kod operacji 32-bit. Co nie oznacza, że nie można, a raczej nawet trzeba, tworzyć oprogramowanie w pełni wykorzystujące możliwości nowej architektury.

Co oferuje architektura 64-bit?

Czemu ma więc służyć proponowana zmiana?! Zacznę od niezbyt odkrywczego i dość nieciekawie brzmiącego stwierdzenia, że samo przejście na architekturę 64-bit nie powoduje automatycznego wzrostu prędkości wykonywania aplikacji 32-bit. Co gorsze, jest duża szansa, że zaobserwujemy efekt odwrotny. Niektóre aplikacje 32-bit będą wykonywały się dłużej, co wiąże się z pewną specyfiką języków wysokiego poziomu, np. C, gdzie rozmiar instrukcji nie jest ściśle zdefiniowany i zależy od rozmiaru wartości całkowitej (int), jakiejś danej oraz konkretnej implementacji. Jeżeli w wyniku tego rozmiar wszystkich przeprowadzanych operacji zostanie określony na 64-bit, to zajmą one więcej pamięci, w tym również cache. W rezultacie aplikacja będzie wykonywała się dłużej. Problem rozwiązano definiując w procesorze rozmiar danych aplikacji 32-bit na 32-bit! Masło maślane, ale okazało się skuteczne. Pięknie, ale gdzie są wreszcie jakieś korzyści ze zwiększenia liczby kosztownych tranzystorów i wzrostu ilości wydzielanego ciepła?! Pierwszą korzyścią jest możliwość działania na o wiele większych liczbach. W praktyce dotyczy to głównie kilku specjalizowanych aplikacji, stosowanych do obliczeń naukowych (np. Maple). Drugą dziedziną, gdzie doskonale sprawdza się architektura 64-bit jest kryptografia. Ale jest jasne, że te dziedziny stanowią margines zastosowań i nie ma co marzyć o sukcesie na rynku masowym. A więc gdzie są konfitury?! Otóż architektura 64-bit pozwala zapomnieć o limicie 4 GB pamięci RAM! Przypomnijmy, że teoretycznie: 2³²=4,3 miliarda, natomiast 2⁶⁴=(4,3 miliarda)². Nawet trudno sobie wyobrazić taką liczbę. W praktyce przestrzeń adresowa A64 określana jest jedynie 48 bitami, ale i tak wynosi to 256 Tb. Jednak dla Jana Nowaka nie jest to czynnik decydujący - jeszcze długi czas aplikacje "domowe" nie będą wymagały posiadania na pokładzie takiej ilości pamięci. Obecnie 512 Mb, a w zastosowaniach biurowych nawet 256 Mb, statystycznemu użytkownikowi spokojnie wystarcza. Są jednak programy graficzne (3D Studio max lub Maya), które mają olbrzymi apetyt na RAM i powoli zbliżają się do teoretycznej granicy 4 Gb. Sprawa wygląda zupełnie inaczej jeżeli chodzi o rynek serwerów oraz stacji roboczych. Niewiarygodnie duże ilości składowanych i przetwarzanych informacji już obecnie wymagają używania RAM w maksymalnie możliwej dostępnej ilości. Serwer z możliwością obsługi jedynie 4 GB RAM-u po prostu się "udusi". Mówię tu nie o serwerkach pracujących na potrzeby Internetu osiedlowego, ale o maszynach o wiele potężniejszych, obsługujących światowe centra usług sieciowych lub systemy informatyczne międzynarodowych korporacji. Stosując różne triki oraz rejestry wewnętrzne o większych niż 32-bit rozmiarach obecne procesory 32-bit są w stanie adresować do 16 TB pamięci. Całkiem sporo, ale coś za coś. Oczywiście chodzi o szybkość. Tymczasem "prawdziwa" architektura 64-bit robi to o wiele szybciej i zupełnie naturalnie, w ramach przypisanych sobie możliwości technicznych. Ponadto jeszcze jedna rzecz wydaje się być dość ważna: lepiej dzisiaj przygotować "miękkie" przejście pod potrzeby jutra, niż zostać zaskoczonym wymaganiami, którym nie będziemy w stanie sprostać. A postęp i wymagania w tej akurat branży rosną w zawrotnym tempie.

Gdzie ta rewolucja?

Mówiąc szczerze, to powyższe wywody zapewne nie wywarły na nikim piorunującego wrażenia. Na mnie też nie! Gdybym w tym momencie zakończył felieton to zapewne Czytelnicy zgodnym chórem by orzekli, że tym razem się nie przemęczyłem i wyraźnie obniżyłem loty. Aby tego uniknąć postanowiłem odpowiedzieć na jeszcze jedno pytanie: dlaczego procesory A64 robią taką oszałamiającą karierę?! I to pomimo, praktycznie biorąc, braku znaczącego wsparcia ze strony producentów oprogramowania, systemu operacyjnego i sterowników. O faktycznym i realnym sukcesie można będzie mówić gdy pojawi się pełnowartościowy(?!) 64-bit OS (Longhorn). To, niestety, nie nastąpi zbyt szybko. ATI i nVidia doceniają wagę zagadnienia i powoli opracowują 64-bit sterowniki do swoich kart. Nie śpieszą się, skoro i tak nie ma pełnowartościowego środowiska, w którym mogły by one pracować. Na razie pojawiają się ich wersje beta, z licznymi błędami, zmniejszającymi wydajność. Poza aplikacjami naukowymi nie ma zbyt wiele programów użytkowych w pełni wykorzystujących możliwości technologii 64-bit. Jednym z nich jest program "Panorama Factory 2.4", służący do łączenia w jedno panoramiczne zdjęcie, kilku fotek tej samej okolicy. Przeprowadzone testy wykazały

25% oszczędność czasu w porównaniu do wersji 32-bit. W niektórych przypadkach wykonanie operacji łączenia było możliwe jedynie w wersji 64-bit z uwagi na konieczność dostępu procesora do zbyt dużych bloków pamięci, oraz jego chęci do wykonywania zbyt wielu czynności jednocześnie. Jak na razie brak również gier napisanych specjalnie do pracy w środowisku 64-bit. Pokonanie wszystkich przeszkód jest jednak tylko kwestią czasu. Miejmy nadzieję, że nie sięgającego poza 2006r. Wszystkie wymienione elementy muszą powstać i działać niezawodnie, aby umożliwić zademonstrowanie na co naprawdę stać te procesory. Nie można powiedzieć, że "w temacie" nic się nie dzieje, ale dzieje się o wiele za wolno. Trudno. Dobrze, że w ogóle coś się dzieje! Bez wpadania w przesadę, ale A64 wyprzedziły swój czas, nadając nowy sens przestarzałej technologii x86. Nie mam tu zamiaru umniejszać osiągnięć konkurencji, która może się pochwalić np. Hyper Threadingiem, znacznie zwiększającym wydajność w zastosowaniach multimedialnych, oraz wyższą częstotliwością zegara. Co prawda, to prawda! Ale z kolei kompleksowe rozwiązanie w A64 problemu komunikacji z pamięcią poprzez umieszczenie jej kontrolera w CPU, rezygnacja z klasycznego FSB na rzecz Hyper Transportu i perspektywiczne spojrzenie na możliwość pracy wielordzeniowej (przełącznik X-bar) wydaje się o rekompensować. Na dzień dzisiejszy, zwłaszcza w grach, procesory A64 nie mają sobie równych. A jest to dziedzina, która bardzo silnie wpływa na zachowania rynku. Trzeba też jasno powiedzieć, że pracując z aplikacjami 32-bit procesory A64 nie mają możliwości wykazania swojej prawdziwej wartości. Tak naprawdę lwi pazur mogą pokazać dopiero przy pracy w środowisku w pełni 64-bit. Powody są dwa: dopiero wtedy są dostępne ich wszystkie rejestry oraz wreszcie pojawia się możliwość swobodnego operowania o wiele większymi blokami pamięci! Takim środowiskiem są systemy operacyjne obsługujące serwery. I jest to druga dziedzina, w której procesory A64 odnoszą zasłużony sukces, pokonując konkurencję ceną i osiągami. Doszło do tego, że Dell, sztandarowy współpracownik Intel’a, poważnie rozważa produkcję serwerów opartych o Opterony, chociaż oficjalnie głosi, że na procesory AMD brak zapotrzebowania na rynku! Co za hipokryzja! Cóż, w biznesie nie ma sentymentów, liczą się pieniądze!

Jak do tego doszło?

Kiedy inżynierowie AMD rozpoczęli pracę nad nowym (K8) procesorem, stanęli przed prawdziwym wyzwaniem. Jak rozwinąć architekturę liczącą sobie więcej niż 20 lat, która obsługiwała 7 kolejnych generacji? I czy w ogóle jest to dobry pomysł? Odpowiedź na pierwsze pytanie kryje się w historii rozwoju technologii x86. Poczynając od procesora 8080, który stał się podstawą konstrukcji procesora 8086, poprzez 80286, 80386, 80486 do Pentium. Ewolucja ta, tak naprawdę, była kwestią wyboru koncepcji działania procesora: CISC (Complex Instruction Set Computer) lub RISC (Reduced Instruction Set Computer). Do 80386 włącznie, procesory Intel’a były procesorami CISC. No tak! Wtajemniczeni wiedzą w czym rzecz! Ale cała reszta?! Muszę w skrócie wyjaśnić o co chodzi. Architektura CISC to procesor cechujący się: dużą ilością złożonych i mających zmienny format (mikrokodowanych) rozkazów, małym zestawem rejestrów strukturalnych oraz zazwyczaj rozbudowanym sposobem adresowania. Podstawowe cechy architektury RISC to zastosowanie: niewielkiej listy prostych rozkazów, stałej długości rozkazu, dużej ilości uniwersalnych rejestrów wewnętrznych, uproszczenie trybów adresowania i, zazwyczaj, zastosowanie architektury load/store (ładuj/zapisz), czyli rozdzielenie rozkazów operujących na pamięci od reszty rozkazów. Wszystko jasne? Pewnie nie, ale prościej się nie da! Aby wyjaśnić pewne pojęcia, trzeba znać inne, które wymagają znajomości kolejnych, itd. Błędne koło! Trudno! Nowo powstały Pentium, ze swoją szyną danych do pamięci o szerokości 64-bit, mógł jednocześnie wykonywać dwie instrukcje, ponieważ posiadał również 2 jednostki ALU. Było to dobre rozwiązanie, ale tylko chwilowo! Intel uświadomił sobie, że będzie miał kłopot z konkurencją (Apple, IBM, Motorola), która przeszła na technologię RISC, wyraźnie zyskując na szybkości działania swoich CPU. Wtedy Intel wykonał doskonały ruch: przebudował częściowo wewnętrzną architekturę procesora tak, aby nadchodzące do niego instrukcje x86 były dzielone na mniejsze "porcje" i wysyłane do jednostek wykonawczych. Pozwoliło to na pracę quasi RISC, podnosząc znakomicie wydajność Pentium Pro, jednocześnie zapewniając kompatybilność "wstecz" nowych CPU, gdyż pozostała część procesora pozostała niezmieniona. Innymi słowy Pentium Pro stał się procesorem RISC, emulującym procesor CISC! Podnosząc częstotliwość zegara CPU, Intel bez problemu mógł rywalizować na rynku z procesorami konkurencji. Tymczasem atak nadszedł nie z platformy procesorów RISC, ale z najmniej spodziewanej strony - słabej ekonomicznie AMD! Powstały Athlon działał na podobnej zasadzie jak Pentium: dzielił nadchodzące instrukcje x86, ale posiadał więcej jednostek wykonawczych, jednocześnie usiłując zbliżyć się możliwościami w obliczeniach zmiennoprzecinkowych do osiągnięć procesorów RISC, co udało się osiągnąć jedynie częściowo - głównie z uwagi na niewystarczającą ilość wewnętrznych rejestrów. Athlon, oczywiście, nie mógł konkurować z takim procesorem jak Alpha 21264, ale czynił to z powodzeniem z procesorami Ultra Sparc i PowerPC. Inżynierowie AMD postanowili działać na zasadzie - im więcej, tym lepiej! Przybyło dekoderów, jednostek wykonawczych i w rezultacie - pracy równoległej wewnątrz procesora. Efekt: wzrost wydajności przy nie zmienionym zegarze. Był taki moment, że nowo powstałe Athlony były wydajniejsze od intelowskiego Pentium! Kontratak giganta był szybki i skuteczny. Wzrost częstotliwości FSB załatwił sprawę, ale i tak procesory AMD dzielnie konkurowały z potentatem. Kto wie, czy właśnie wtedy nie zrodził się w Intel’u fatalny pomysł "załatwienia" konkurenta częstotliwością. Okazał się on drogą do nikąd, ale nie uprzedzajmy faktów. Przecież właśnie powstawał rdzeń Willamette, wyposażony w potężną jednostkę do obliczeń zmiennoprzecinkowych - FPU (Floating Point Unit) oraz nowe instrukcje SSE2, oferujące obliczenia skalarne o podwójnej precyzji. Nie da się ukryć, że w tym momencie jedynie Intel mógł sobie pozwolić na tak szeroką modyfikację rdzenia. Oczywiście chodziło o koszt wprowadzenia tak daleko posuniętych zmian. Okazało się jednak, że wprawdzie wydajność nowego Pentium wzrosła, ale nie na tyle aby pozbawić AMD możliwości konkurowania. Głównie ceną, co było powodem licznych problemów AMD. W rezultacie walki konkurencyjnej, Athlona uczyniono jeszcze bardziej superskalarnym, a P4 - szybszym. Wprawdzie można naiwnie uważać, że wystarczy do rdzenia CPU dołożyć jeszcze więcej jednostek wykonawczych, rejestrów, pipelines, zwiększyć częstotliwość pracy i problem jest rozwiązany. Niestety to złudzenie, wynikające z tej samej przyczyny, którą opisuje stary przykład: jeden człowiek buduje dom rok, dwóch - pół roku, czterech - w kwartał itd. Jednak nie da się wybudować domu w 1 dzień, bo przecież 365 robotników nie jest w stanie pracować jednocześnie, pomijając oczywiście wymagania wynikające z technologii. Jak więc "wydobyć" większą wydajność z przestarzałej architektury x86, której głównym fundamentem jest powolna szyna ISA? Jeszcze trochę cierpliwości. Wprawdzie za sprawą szyny PCI można było odesłać szynę ISA do muzeum, ale to w niczym nie zmieniało problemów architektury. Wydawało się, że w 1993 roku procesory PowerPC wieszczą koniec architektury Intel'a. Nic takiego się nie zdarzyło, pomimo wyraźnych starań Wielkiej Trójki (Apple, IBM, Motorola) aby tak się stało, a procesor Alpha Digital został wykupiony przez Intel’a! Co nie udało się takim potentatom, (również finansowym) jak mogło się udać firmie skazanej na kompatybilność z ISA x86 (lub PCI, co w sumie na jedno wychodzi)?! Bo przecież całkiem zwyczajnie AMD nie było staćna tworzenie i promowanie nowej architektury! Zadanie wydawało się niemożliwe do rozwiązania. A jednak...

AMD64

Rozwiązanie, jak to często bywa, ukryte było w przeszłości! Ponieważ "wyduszenie" większej wydajności z architektury x86 było by trudne i bardzo kosztowne, AMD postanowił zmienić przedmiot swojego działania, oferując wsparcie dla programów 64-bit. Nie była to technologia, której potrzebował Jan Nowak, ale stacje robocze i serwery - jak najbardziej! Ponadto Intel (przynajmniej oficjalnie) odżegnał się od adaptowania architektury x86 na potrzeby aplikacji 64-bit. AMD pozostała sama na placu boju, kreując standardy, które wreszcie pozwoliły nie oglądać się na to co zrobi konkurent. Przypomnę tu jedynie historię technologii Clackamas, następnie przechrzczonej na EM64T (Intel wreszcie się połapał co mu bezpowrotnie może umknąć) oraz bitu NX (No eXecute), oficjalnie uznanego przez Microsoft za obowiązujący. Aby przejść na architekturę 64-bit, zachowując jednocześnie pełną kompatybilność z 32- bit, AMD sięgnęła do historii. Tak jak zrobił to Intel przechodząc z 16-bit na 32-bit, AMD zaprojektowała rejestry GPR o wymiarze 64-bit. Ale, przeciwnie niż Intel, inżynierowie AMD nie poprzestali na tej prostej operacji, lecz rozwiązali podstawowy problem architektury x86, zwiększając liczbę rejestrów GPR do 16. Możliwość tak prosta, że wcześniej nie zauważona! Każdy procesor poza "oficjalnymi" rejestrami ma ich w swojej strukturze jeszcze sporą liczbę. Wykonują one różne zadania, wynikające głównie z rozwiązywania problemów wynikłych na skutek wykonywania instrukcji kodu. Nie są one "widziane" przez kompilator i w konsekwencji nie mogą być użyte do poprawienia wydajności procesora. Wprawdzie procesory RISC mają aż 32 rejestry GPR, ale i tak wzrost wydajności wynikający z prostego zabiegu jest spektakularny. Oczywiście dla programów, które uwzględniają ich istnienie. A powstaje ich coraz więcej. Projekt Hammer "odświeżający" starą architekturę musiał rozwiązać jeszcze jeden poważny problem: FPU (Floating Point Unit), czyli jednostka obliczeń zmiennoprzecinkowych. Pomimo wysiłków inżynierów Intel’a i AMD wydajność tej jednostki była o wiele niższa niż w procesorach RISC. Problem wynikał z architektury FPU, składającej się z 8 rejestrów, zorganizowanych w pseudo stos. Na każdą wykonywaną instrukcję był używany tylko jeden operand, pozostałe były składowane na wierzchołku stosu. Aby rozwiązać problem, AMD zaprojektowała rozszerzenie instrukcji, zwanych TFP (Technical Floating Point). Ich celem było osiągnięcie wydajności FPU na poziomie najlepszych procesorów RISC. Aby to osiągnąć, AMD zrezygnowała z przestarzałej koncepcji stosu, zastępując ją "płaską" konstrukcją z wielu rejestrów. W rezultacie ta koncepcja nigdy nie została wdrożona, ponieważ AMD spostrzegł, że może zrobić coś o wiele lepszego! Po prostu użył instrukcji SSE2 Intel’a, które spełniały tą samą rolę, którą miały spełniać TFP! Tym prostym sposobem zyskali możliwość korzystania przez swoje procesory z wszystkich optymalizacji przewidzianych dla SSE2 oraz specjalizowanego kompilatora. Niezależnie od tego AMD zwiększył do 16 ilość rejestrów o podwójnej precyzji, obsługujących obliczenia zmiennoprzecinkowe. Pozostałe ulepszenia, wprowadzone w nowym rdzeniu wykonawczym, były niewielkie. Wydłużono nieznacznie pipeline (o 2 stopnie), co pozwoliło łatwiej podnosić częstotliwość zegara, zwiększono rozmiar niektórych buforów, ulepszono algorytm działania oraz rozmiar rejestrów zajmujących się przewidywaniem skoków wykonywanego programu - z 4Kb do 16 KB. Wprowadzono również szereg ulepszeń w organizacji pracy pamięci cache L2 i L1, zwiększając z 256 do 512 ilość wejść do L2 i z 24 do 40 ilość wejść do L1. Jednakże największe zmiany wprowadzono w systemie zarządzania pamięcią. To był pomysł pochodzący z procesora Alpha 21364 - kontroler pamięci zintegrowano w rdzeniu procesora! Tradycyjne kontroler ten znajduje się w mostku północnym (NB). Nawiasem mówiąc jest to jeden z powodów dla których standard BTX nie za bardzo się nadaje do płyt głównych obsadzonych procesorami AMD. Zmiana lokalizacji pozwala ogromnie zmniejszyć czas dostępu do pamięci RAM. Testy wykazały, że A64 ma czas dostępu do pamięci o 40% mniejszy niż Athlon XP. W rezultacie wydajność wyraźnie rośnie. Jest jednak pewna pułapka w tym rozwiązaniu: aby stosować pamięć DDR2 (kiedyś będą one miały parametry 2-2-2-5, tak jak obecnie DDR1) trzeba generalnie przekonstruować procesor i kontroler pamięci. To nie jest zadanie ani łatwe ani możliwe do szybkiego rozwiązania. Jednak AMD uznała, że korzyści przeważają nad niedogodnościami. Ostatnim ulepszeniem było zastąpienie Hyper Transportem tradycyjnej szyny FSB (Front Side Bus). W zasadzie działania Hyper Transport jest podobny do szyny PCI-e, łącząc bezpośrednio elementy przekazujące sobie dane. Oczywiście szybkość przekazywania danych może być ustalana stosownie do potrzeb i możliwości hardware. Wzrost częstotliwości Hyper Transportu jest najprostszym sposobem zwiększenia wydajności procesora. Pierwsze Opterony pracowały z HT=800 MHz. Obecnie Opteron pracuje z HT=1 GHz, a jego wydajność wzrosła o około 25%. Całkiem nieźle, jak na konieczność ulepszenia i poprawienia wyłącznie parametrów PCB! I w ten oto sposób niemożliwe stało się możliwe, przyprawiając Intel’a o potężny ból głowy. A przecież w odwodzie jest jeszcze procesor K9! To wielka niewiadoma (hyper threading?) ale sama perspektywa, że prawdopodobnie w 2006 roku ujrzy on światło dzienne, już dzisiaj spędza sen z powiek prezesów Intel’a. Czy będą mogli coś mu przeciwstawić? Pożyjemy - zobaczymy!

Co dalej?

Niemal tradycyjnie stawiam to pytanie, ale któż zna pełną odpowiedź? Jedna rzecz wydaje się pewna: obaj konkurenci będą MUSIELI zmierzyć się z problemem przejścia na wymiar 65 nm. Wydaje się też, że obie firmy stawiają na procesory wielordzeniowe. Tutaj kończą się podobieństwa. Niezależnie od rewolucyjnych zmian w procesorach A64, ktoś w AMD miał przebłysk geniuszu wprowadzając do nich przełącznik X-bar, dzięki któremu połączenie kolejnych rdzeni w procesor wielordzeniowy jest banalnym zabiegiem. Niestety, obecna architektura A64 praktycznie wyklucza stosowanie Hyper Threadingu. W "rewanżu" Intel ma potężny problem właśnie z połączeniem dwóch rdzeni w procesor dwurdzeniowy. Jak pewnie pamiętacie, rzecz polega na koherencji danych zawartych w cache L2 obu rdzeni. Czyli jak zmienia się dana zawarta w cache L2 jednego rdzenia, to powinna się ona również zmieniać (na taką samą!) w cache L2 drugiego. AMD ma do tego celu X-bar i HT. Intel musi to załatwić szybką szyną lub cache L3. Według ostatnich informacji dwurdzeniowe procesory Intel’a będą pracowały z wyłączonym Hyper Threadingiem! Dlaczego? Podejrzewam, że szyna łącząca cache L2 obu rdzeni nie jest w stanie obsłużyć 4 procesorów z powodu zbyt małej przepustowości. Ale to są tylko moje domysły. Zobaczymy niebawem jak to wszystko sprawdzi się w praktyce, bo rywale zapowiadają procesory dwurdzeniowe na 2005 r. Ale jest faktem, że AMD już zaprezentowała działającą próbkę dwurdzeniowego Opterona. Kompatybilnego z socketem 940! Czy można przecenić wagę tego faktu?! Prosta wymiana CPU na płycie serwera zapewni niebagatelny wzrost jego wydajności, oceniany na 30 - 55%. Platformy socket 939 zapewne również, tylko nieco później. Plotka głosi, że na analogicznym pokazie konkurent zaprezentował raczej dwa procesory w jednym rdzeniu niż procesor dwurdzeniowy. Subtelna, ale jakże istotna różnica. Cierpliwości, do 2005 roku pozostało tylko 2 miesiące!

Grafika 64-bit

Jest jeszcze jeden element składowy zagadnień 64-bit. Grafika! I nie chodzi mi tu o sterowniki i szybkość działania ale o paletę barw, którą będzie oferowała nowa technologia. Przecież już obecnie są to miliony kolorów! A ich ilość nieprawdopodobnie (przynajmniej teoretycznie) się zwiększy. Nie jestem specjalistą w dziedzinie monitorów ale odnoszę wrażenie, że przy obecnych rozdzielczościach oferowanych przez technologie CRT lub LCD, praktyczne wykorzystanie powstałych możliwości jest trudne do wyobrażenia. Czyżby miały to udostępnić dopiero hologramy? A może się mylę? Widzę jeszcze inny problem. Obecne GPU pracujące w środowisku 32-bit mają tyle rejestrów i szyn o wiele większej szerokości, że chyba jedynym sensownym kryterium (przynajmniej dla mnie) określającym ilu bitowa jest karta graficzna, jest przyjęcie wymiaru pakietu informacji graficznej przesyłanego szyną PCI-e. I tutaj niespodzianka! Dane ATI mają wymiar 32-bit, natomiast nVidii - 64 bit. Rozwiązania techniczne nie są moją specjalnością i dlatego trudno mi ocenić, jaki będzie miało to wpływ na konstrukcję przyszłych GPU, które będą pracowały w środowisku w pełni 64-bit. Ale intuicja podpowiada, że ATI już teraz ma nad czym myśleć i pracować, aby w przyszłości nie dać się wyprzedzić konkurentowi.

Zakończenie

Do pełnego naświetlenia zagadnienia 64-bit brakuje w felietonie analizy możliwości i ograniczeń typowych procesorów RISC. Jednak postanowiłem "odpuścić". Trochę z lenistwa, a trochę z przeświadczenia, że procesory RISC też dadzą sobie radę z aplikacjami 64-bit. Przecież najnowszy, wielordzeniowy, prawdziwy SMT (Simultaneous Multi Threading) procesor IBM (Power5), może być wzorem rozwiązywania problemów związanych z projektowaniem procesorów RISC. A więc raczej można być spokojnym o ich przyszłość w zastosowaniach 64-bit. A co słychać u AMD? Na chwilę obecną, opierając się na informacjach z sieci wydaje się, że problemy związane z przejściem na technologię 90 nm mają się ku końcowi. Mój niepokój budzi jedynie produkcja FX55 w technologii 130 nm. Moc rozpraszana tego CPU wynosi 104 W i jest o 1W większa niż konkurencyjnego Xeona, aka NOCONA! Zapewne jakieś racjonalne powody takiej decyzji istnieją. Gdy światło dzienne ujrzy FX55 w technologii 90 nm z mniejszą mocą rozpraszaną, AMD zamknie ważny etap swojej walki o wypromowanie procesorów 64-bit. Znając pracowitość i upór Azjatów można mieć nadzieję, że stanie się to niebawem. Natomiast Intel ma większe problemy. Oto najpoważniejsze: nie udało się przekroczyć zaczarowanej granicy 4 GHz, zrezygnowano z projektu procesora Tejas, diamentowa warstwa izolacyjna nie wytrzymuje wysokich temperatur i powoduje duże "wycieki" energii w rdzeniu, wreszcie architektura Prescott'a nie za bardzo nadaje się do pracy wielordzeniowej.

Chyba wystarczy? Wprawdzie i w Intel’a są zdolni inżynierowie, ale zawsze jest jakiś limit możliwości usunięcia problemów. Bez nowych rozwiązań kłopoty będą się powiększać, a na samej reputacji i Dell'u nie da się "jechać" zbyt długo. Intel MUSI maksimum za 2 lata zaprezentować nowy, doskonały procesor. Lub przynajmniej w bardzo znaczący sposób zmodyfikować rdzeń Prescott'a. Tylko jakoś nic nie słychać o takim przedsięwzięciu. Czyżby tajne/poufne?! W przeciwnym wypadku powyższy żart graficzny może zacząć nabierać realnego kształtu, a jedynym zmartwieniem AMD będzie znalezienie producentów swoich CPU, bo popyt przewyższy podaż. Z praw ekonomii wynika, że ich cena wtedy wzrośnie! Hmm... Dobrze życzę AMD, ale ta perspektywa niezbyt mi się podoba! Jedno jest pewne: rozpoczął się proces, który być może zakończy się dopiero w momencie gdy będziemy przechodzić na technologię 128-bit.

URAN

Za zgodą dzikie.net

Zobacz też:

1. Hyper Threading (HT)
2. Procesory wielordzeniowe
3. Nowe szaty króla- zakończenie, czyli trzy potwory i spółka!
4. Budowa PC [podstawy]
5. PCI Express

Średnia ocena:

Bardzo ciekawy artykuł.

Autor (wymagane):
Treść (wymagane):
Przepisz kod z obrazka (wymagane):