Procesor PowerXCell 8i. Zapomniany bliźniak procesora PlayStation 3
Procesor IBM Cell, napędzający PlayStation 3, to układ, którego raczej żadnemu z graczy szczególnie przedstawiać nie trzeba. Owiany aurą wyjątkowości – mocno niesłusznie, ale jednak – stał się synonimem wkroczenia konsol w erę HD, a wielu nawet po latach z wypiekami na twarzy czekało na ujawnienie jego rzekomo ukrytej mocy obliczeniowej. Niewielu natomiast wie, że Cell Broadband Engine, jak brzmi pełna nazwa kultowego czipu, miał braciszka – układ PowerXCell 8i. Ten również zapisał się w historii, ale nie kolejną widowiskową odsłoną Uncharted czy Motorstorm, lecz jako element legendarnego Roadrunnera, pierwszego superkomputera na świecie, który przekroczył barierę 1 petaflopsa.
Premierowe PlayStation 3 miało wymiary 325 x 98 x 274 mm i uważane było powszechnie za konsolę dość spasioną i niezgrabną. Zresztą, chętnie porównywano je do chlebaka, co niejako mówi samo za siebie. Później zawstydzi je co prawda Xbox One, pieszczotliwie zwany magnetowidem, a ostatecznie PlayStation 5 ps. „wieża Saurona”, ale nie zmienia to faktu, że do maluszków trzecia konsola stacjonarna Sony nie należała. Roadrunner to jednak „trochę” inna kategoria wagowa, bo jego liczby to 560 i 296. Odpowiednio metrów kwadratowych oraz szaf serwerowych. Tak, to był faktyczny superkomputer. Nie żaden Mac Pro na biurko filmowca czy inne wypasione monstrum z topowym GeForce’em, chłodzeniem cieczą i LED-ami, ale wielkoskalowa inwestycja, zbudowana dla Departamentu Energii USA. Kompleks stanął w Narodowym Laboratorium Los Alamos w stanie Nowy Meksyk. Nawiasem mówiąc, tym samym, w którym Robert Oppenheimer zbudował w 1942 roku bombę atomową.
Nie Cell, ale PowerXCell 8i i nie jeden, lecz 12 999
Siłą rzeczy Roadrunner nie miał jednego procesora PowerXCell 8i. Nie miał też takich dwóch, dziesięciu ani nawet stu. Miał na pokładzie 12 999 jednostek marki IBM i to wciąż nie wszystko, bo trzeba doliczyć do puli jeszcze dwurdzeniowe AMD Opterony. W sumie to 6912 takich chipów, co z perspektywy konsumenckiej brzmi kompletnie absurdalnie, ale obrazowo oddaje skalę projektu. Wyraża też bardzo dobitnie wyzwania wokół architektury Cell, która stworzona pod powtarzalne i masowe obliczenia zmiennoprzecinkowe, nieszczególnie radziła sobie w zastosowaniach związanych z zarządzaniem i logiką klastrów. Tak więc podczas gdy sprzęt IBM zapewniał brutalną siłę, system operacyjny, operacje wejścia-wyjścia czy koordynowanie pracy musiało spocząć na barkach układów marki AMD. Mimo to Roadrunner w ciągu zaledwie sześciu lat przeszedł na emeryturę, bo choć w chwili debiutu bił rekordy wydajności, szybko okazał się nieefektywny energetycznie i uciążliwy w programowaniu. Dziwne, prawda? Cell uciążliwy w programowaniu, kto by pomyślał.
Nie zmienia to faktu, że Cell BE z PS3 i PowerXCell 8i to procesory wyraźnie odmienne. Na papierze zbudowane w myśl tych samych założeń, składające się z rdzenia zasadniczego PowerPC v2.02 z dwoma wątkami SMT, a także ośmiu koprocesorów SPE, jednak prócz ogólnie pojmowanej makroarchitektury – i marketingu Sony, że PS3 ma procesor z superkomputera – różniło je naprawdę wiele. W istocie rzeczy konsolowy układ – podobnie jak duża część innych, typowo konsumenckich jednostek – zupełnie nie nadawał się do zastosowania w poważnej matematyce. A ja spróbuję wyjaśnić prostymi słowami dlaczego.
W pewnej zmyślonej fabryce
Konsolowy Cell, mimo 128-bitowych rejestrów, zoptymalizowany został pod obliczenia na liczbach zmiennoprzecinkowych pojedynczej precyzji, czyli tzw. FP32. Innymi słowy: chodzi o działania na liczbach 32-bitowych. Żeby to jednak zrozumieć, warto pokrótce omówić, jak działają wydajne procesory – a są bardziej linią montażową w fabryce, gdzie rozkaz przechodzi przez kolejne stanowiska, niż rzemieślniczą manufakturą, w której pojedynczy robotnik musi wykonać rękodzieło od deski do deski. Procesor pobiera rozkaz, dekoduje i wykonuje, po czym uzyskuje dostęp do pamięci i – zależnie od instrukcji – zapisuje w niej dane bądź odczytuje, a na koniec musi jeszcze umieścić wynik w rejestrze. Pierwsze procesory konsumenckie, niczym przykładowy chałupnik, mozolnie opracowywały każdy etap, działając ściśle sekwencyjne i szeregowo. Niemniej Cell należy już do procesorów potokowych, przez co należy rozumieć, że dekodując jeden rozkaz, może już od razu pobierać drugi. Właśnie jak przemysłowa fabryka, gdzie żaden stojący wzdłuż taśmy pracownik nie ma ani chwili wytchnienia, bo gdy dokręci śrubkę w jednym egzemplarzu, z marszu podjeżdża do niego kolejny. Sam potok to z kolei analog taśmy produkcyjnej, wzdłuż której ulokowane są stanowiska kolejnych robotników. Dla kronikarskiej uczciwości nadmienię, chip IBM był do tego superskalarny, więc mógł pobrać i wysłać do wykonania dwie instrukcje na raz (ang. dual issue), czyli kontynuując analogię, taśmy na dodatek jechały dwie.
Dzięki potokowości, w jednym cyklu zegara – czyli przy przejściu pojedynczego impulsu elektrycznego – procesor ma zdolność wykonania kilku operacji w tym samym czasie. Przy czym nie należy mylić tego pojęcia z liczbą rdzeni czy wątków, które w realiach fabryki powinny być reprezentowane przez zupełnie inne linie montażowe. Potok jest koncepcyjnym odpowiednikiem jednej linii z kilkoma stanowiskami, a cykl zegara to brygadzista, który rytmicznie przyklaskując, narzuca załodze tempo pracy. A ile przy takiej taśmie jest stanowisk? – zapytacie. To już zależy od konkretnej architektury. Zarówno Cell BE, jak i PowerXCell 8i miały ich po siedem, ale na przykład współczesny im Pentium 4 z rodziny Prescott aż 31. Tym niemniej, co należy bezwzględnie zaakcentować, dłuższy potok nie zawsze jest lepszy, a zbyt długi – jak ten w konstrukcji Intela – jak wiemy po latach, właściwie z zasady jest zły. Kiedy wskutek błędnego przewidywania skoku, na taśmę trafi wadliwa partia towaru, potok musi zostać ponownie napełniony. Trwa to tym dłużej, im dłuższy jest potok.
Jeszcze mała dygresja i do rzeczy
Poza tematem: przewidywanie skoków, zwane też przewidywaniem rozgałęzień, to kolejna cecha charakterystyczna współczesnych procesorów. Cell również z niej korzystał. Dążąc do płynnej pracy bez przestojów, chip czasem zgaduje wyniki instrukcji warunkowych zanim je wykona. Nie musi tym samym oczekiwać na dokładny wynik jednej operacji, by rozpocząć kolejną. Wprawdzie na pierwszy rzut oka może brzmieć to niczym epizod z pamiętnika wróżki Salomei na multipleksie, ale w nowoczesnej, dynamicznej formie nie ma z gusłami zbyt wiele wspólnego, choć oczywiście wymaga pewnej schludności kodu. Przykładowo, masz N liczbę zamówień w swoim e-sklepie i chcesz, aby procesor policzył odsetek tych z reklamacją w bazie danych. Jeśli jako dane wejściowe podasz mu chaotyczny zrzut bazy i nakażesz selekcję prostym warunkiem if, wtedy faktycznie robi się wróżka Salomea. Kiedy jednak posortujesz najpierw rekordy według ich statusu, korzystając choćby z zapytania SQL, to reklamacje pojawią się seriami. Po kilku pierwszych układ zapisze wynik w buforze, a błędna predykcja wystąpi dopiero na końcu listy.
Ale wróćmy do sedna, nie o jakość predykcji tu chodzi. Elementarny problem Cella polegał mianowicie na tym, że o ile z operacjami FP32 w swoim 7-stopniowym potoku radził sobie jak wyżej, o tyle przy FP64 tak nie było. W danej chwili w potoku mogła znaleźć się tylko jedna operacja zmiennoprzecinkowa podwójnej precyzji, więc nawet na dość trywialną instrukcję pomnóż i dodaj (ang. Fused Multiply-Add – FMA) marnował mnóstwo cykli zegara. FMA, choć co do zasady reprezentuje raz zaokrąglony wynik działania A x B + C, stanowi proces zaskakująco złożony sprzętowo. Zakulisowo procesor musi bowiem kolejno: wykonać mnożenie i wyrównać wykładniki, by ustalić rząd wielkości liczb, a następnie dodać, przeprowadzić normalizację – wynik dodawania może nie być zgodny z klasycznym formatem zmiennoprzecinkowym, więc trzeba to skorygować – i jeszcze zaokrąglenie. Z tym że w grach ma to znaczenie porównywalne do pogody w Australii dla Polaka, bo już FP32 oferuje dokładność rzędu ułamków milimetra w kilkukilometrowych lokacjach. Jasne, są od tej reguły pewne wyjątki, jak mierzące miliardy kilometrów podróże w Star Citizen, ale to zjawisko niszowe nawet dzisiaj, a co dopiero w 2006 roku, gdy debiutowało PlayStation 3. Co innego w przemyśle.
// Pseudokod pokazujący efektywność cyklową operacji FP64 (Multiply-Add) w SPE
Dla każdej pary wektorów A i B o rozmiarze N:
{
// --- ARCHITEKTURA: Klasyczny Cell BE ---
// Jednostka FP64 jest niemal w pełni emulowana lub ma bardzo niską przepustowość.
// Wykonanie operacji FMA (Fused Multiply-Add) zajmuje wielokrotnie więcej cykli.
Rozpocznij_Pomiar_Czasu(Cell_Timer)
Dla i = 0 do N krok 1:
{
// Sprzęt potrzebuje wielu cykli na rozbicie i obliczenie 64-bitowego mantysy/wykładnika
Wynik_Cell[i] = FMA_FP64_Emulated(A[i], B[i], C[i]) // ok. 14-30 cykli na operację
}
Zatrzymaj_Pomiar_Czasu(Cell_Timer)
// --- ARCHITEKTURA: PowerXCell 8i ---
// Sprzętowo zoptymalizowane potoki FP64 (wsparcie IEEE 754 w pełnej prędkości).
// Pełna przepustowość wektorowa FMA podwójnej precyzji na cykl.
Rozpocznij_Pomiar_Czasu(PowerXCell_Timer)
Dla i = 0 do N krok 1:
{
// Pojedyncza, dedykowana instrukcja sprzętowa FMA w trybie potokowym
Wynik_PowerXCell[i] = FMA_FP64_Hardware(A[i], B[i], C[i]) // od 2 do 4 cykli na operację
}
Zatrzymaj_Pomiar_Czasu(PowerXCell_Timer)
}
Aby nie przytkać konsumenckich układów zbędnymi danymi, stosuje się instrukcję zwaną Truncation, która odcina nadmiarowe bity bez zaokrąglania. Można w ten sposób sprawnie wpisać większe liczby, np. 64-bitowe, do mniejszego rejestru 32-bitowego. W konsolowym Cellu była to jedna z technik optymalizacji sprzętowej. Teraz – gracz nie jest w stanie dostrzec, czy cień rzucany przez bohatera ma pojedynczą czy podwójną precyzję, ale w fizyce taka rozbieżność może być zabójcza. Dosłownie. W 1991 roku powtarzający się od wielu dni błąd binarny komputera systemu Patriot przy zapisie dziesiątych części sekundy, skumulowany po 100 dniach, zaowocował błędną o 570 metrów oceną pozycji rakiety Scud. Zginęło 28 amerykańskich żołnierzy, a kolejnych 98 zostało rannych. Ni mniej, ni więcej oznacza to tyle, że żaden poważny komputer na przybliżenia pozwolić sobie nie może, więc PowerXCell 8i – w odróżnieniu od pobratymca w PS3 – musiał być dokładny i nie mógł łapać zadyszki przy FP64.
Enhanced Double Precision i DDR2 ECC
Dlatego SPE w PowerXCell 8i otrzymały kompletnie przebudowany potok obliczeniowy, który prymitywną jednostkę FP zastąpił nowatorskim blokiem eDP (Enhanced Double Precision). Ten był w istocie niezależną i wydzieloną jednostką SIMD (od ang. Single Instruction, Multiple Data) w ścieżce wykonawczej, mógł przyjmować instrukcje podwójnej precyzji w każdym cyklu i jako odrębny hardware nie zamrażał potoku FP32. Przetwarzając dwa elementy jednocześnie, przy 128-bitowym rejestrze, potrafił wykonać dodawanie i mnożenie za jednym zamachem, a to wszystko bez przestoju przy pojedynczej precyzji. Był w dodatku zgodny z międzynarodowym standardem technicznym IEEE 754, a wartości zaokrąglał do najbliższej, a nie przez proste odcinanie bitów. Sam IBM szacował, że moc FP64 pojedynczego rdzenia SPE w dedykowanym nauce modelu wynosi 12,8 GFLOPS. Znany z PlayStation 3 Cell BE tyle samo miał osiągać jako cały układ. Ceną strukturalnej rozbudowy krzemu było jednak zwiększone zużycie mocy, a przeniesienie produkcji na proces litograficzny klasy 65 nm – premierowe PS3 miało układ 90 nm – w ocenie inżynierów nie rozwiązywało problemu do końca. W rezultacie PowerXCell 8i musiał otrzymać ponadto specjalny moduł bramkowania zegara, zatrzymujący dostarczanie sygnału do nadprogramowych bloków, gdy chip wykonywał inne, mniej złożone kalkulacje. Jak na ironię, Roadrunner i tak będzie obrywać po głowie za niską ekonomię pracy, ale przynajmniej próbowano.
Cell w PS3 tymczasem miał jeszcze jedną kulę u nogi, pamięci Rambus XDR. Cechujące się szalenie wysoką przepustowością, nie nadawały się do tworzenia systemów klasy przemysłowej z uwagi na wymuszony przez ogromną częstotliwość pracy limit czterech kości na kanał. Do tego zużywały mnóstwo energii, a pozbawione mechanizmów sterowania zasilaniem, na domiar złego piekielnie się nagrzewały. Co jednak kluczowe w przypadku superkomputerów, pamięci XDR nie miały żadnej korekcji błędów. Klasyczna pamięć przesyła dane w paczkach 64-bitowych i nie weryfikuje ich integralności. Zakłócenia elektromagnetyczne, a nawet zwykłe starzenie się sprzętu mogą sprawić, że jeden z bitów będzie błędny. Ostatecznie albo dojdzie do awarii, albo wyniki pracy zostaną zafałszowane. Dlatego profesjonalne systemy korzystają z tzw. ECC, czyli pamięci, które do każdej paczki danych dorzucają jeszcze 8 bitów kontrolnych. Roadrunner poszedł nawet o krok dalej. Rozpraszał dane i bity korekcyjne pomiędzy wieloma fizycznymi kośćmi, dzięki czemu mógł odtworzyć dane nawet w obliczu, gdyby któraś z kości, mówiąc kolokwialnie, poszła z dymem. XDR pasowały tu jak pięść do nosa, więc kontroler wymieniono na DDR2 ECC, by stworzyć coś na kształt - uwaga, luźna analogia - macierzy RAID dla pamięci.
Zupełnie różne układy o zaskakująco zbieżnej ocenie
Oczywiście pomniejszych zmian było więcej, można byłoby rozwodzić się choćby nad pewną ewolucją paradygmatu superskalarności, ale znając życie, artykuł rozwlekł by się do monstrualnych rozmiarów, a Wy pozasypiali. Co chciałem niniejszym zaakcentować, to fakt, że przemysłowy PowerXCell 8i oraz konsolowy Cell BE to dwie wywodzące się z jednej rodziny, ale zasadniczo odmienne konstrukcje. Inna sprawa, że spotkała je zaskakująco zbliżona ocena końcowa. Jeden i drugi był mieszany z błotem za trudności w programowaniu, a między innymi przez to rewolucyjny IBM Roadrunner służbę zakończył już w 2013 roku. Przyznajcie, jak na inwestycję szacowaną szczytowo na 133 mln dolarów, nie jest to osiągnięcie szczególnie spektakularne. Tym bardziej, że jego następca, Cielo, przy nieznacznie wyższej mocy obliczeniowej zużywał ledwie ułamek energii i był ponad dwukrotnie tańszy. Znaczy, skończyło się trochę typowo dla Cella, drogo i niekoniecznie optymalnie.
Zupełnie na marginesie warto dodać, że konsolowy Cell również doczekał się użycia przemysłowego, choć nigdy nie trafił w swojej pierwotnej formie do produktu z zasady profesjonalnego. Hurtowo kupowano sklepowe PlayStation 3 i przerabiano je własnym sumptem. Chyba najgłośniejszy przykład to klaster Condor, należący do Laboratorium Badawczego Sił Powietrznych USA. Naukowcy połączyli 1760 konsol PS3 z systemem Linux, by stosować je głównie do przetwarzania i analizy obrazów satelitarnych, ulepszania sygnałów radarowych i wczesnych badań nad sztuczną inteligencją. Pojedyncza prezycja była dostateczna, a w chwili powstania był to 35. najszybszy superkomputer na świecie. Sony chyba - i być może również IBM - niezbyt było zadowolone z takiej reklamy, bo niedługo potem całkowicie wycięli z firmware’u możliwość instalacji systemu Linux. Trudno się jednak dziwić, gdyż wedle szacunków pomysłodawców, którzy na zrealizowanie systemu przeznaczyli około 2 mln dolarów, dedykowana maszyna o podobnym potencjale, zakupiona od jednego z dostawców, mogłaby lekką ręką kosztować 10-krotnie więcej.
Przeczytaj również
Komentarze (4)
SORTUJ OD: Najnowszych / Najstarszych / Popularnych