Sun Niagara - procesor zupełnie inaczej

Spis treści

O przeznaczeniu i wydajności

Procesor Niagara 2, podobnie jak produkowany już od pewnego czasu pod nazwą handlową UltraSPARC T1 układ Niagara, przeznaczony jest do wykorzystania przede wszystkim w serwerach biznesowych, szczególnie klasy front end. Specyfiką takiej pracy jest obsługa bardzo wielu niezbyt skomplikowanych wątków programu, a często wręcz kilkudziesięciu instancji tego samego procesu, jak to widzimy np. w serwerach WWW, najbardziej charakterystycznej grupie aplikacji front end. Jak uzyskać wysoką wydajność w takim trybie pracy?

Na finalną wydajność procesora składają się dwa czynniki. Pierwszym z nich jest jego wydajność obliczeniowa – mówiąc w uproszczeniu, liczba operacji wykonywanych w jednostce czasu. Drugim, równie ważnym, jest przepustowość, którą należy rozumieć jako objętość danych, jakie w jednostce czasu procesor będzie w stanie pobrać, obrobić i zwrócić do systemu. Środków na uzyskanie większej wydajności jest wiele – przyspieszanie częstotliwości zegara, zwiększanie liczby operacji wykonywanych w jednym cyklu przez stosowanie architektury superskalarnej, czy wreszcie zwielokrotnienie jąder procesora.

W przypadku obciążenia o charakterze silnie wielowątkowym nietrudno zauważyć, że przełączanie procesora pomiędzy kolejnymi obsługiwanymi wątkami wiąże się ze stratą czasu – dla każdego wątku muszą zostać pobrane należące do niego dane. Nie zawsze przełączanie wątków wiąże się z pobieraniem również ich kodu – jeśli pracuje wiele instancji tego samego procesu, stosuje się współdzielenie kodu, który dla wszystkich instancji załadowany jest tylko raz, dzięki czemu jest duże prawdopodobieństwo, że znajdzie się w cache procesora. Ale nawet tylko sama strata czasu związana z pobraniem należących do obsługiwanego wątku danych powoduje, że w miarę wzrostu liczby obsługiwanych procesów i wątków efektywność wykorzystania procesora maleje, by w skrajnym przypadku osiągnąć poziom bliski zera – prawie cały czas procesora angażowany jest w przełączanie wątków. W jaki sposób oddalić tę perspektywę?

Różne twarze wielowątkowości

Jednym ze środków jest procesor pracujący wielowątkowo. Wielowątkowość (multithreading) można realizować na wiele sposobów. Najprostszym z nich, praktycznie występującym we wszystkich współczesnych komputerach, jest wielowątkowość na poziomie systemu operacyjnego, sprowadzająca się do przełączania wątków z chwilą, gdy wątek aktualnie angażujący procesor udostępnił taką możliwość, a system uznał, że pora na obsługę innego wątku. Taki tryb obsługi wielowątkowości nie ma związku z konstrukcją procesora. Wyższy poziom przystosowania do pracy wielowątkowej to „zgrubna” wielowątkowość (coarse multithreading), w której przełączenie obsługi na następny wątek następuje z chwilą, gdy dotychczas wykonywany wyczerpał zapas danych lub kod zgromadzony w pamięci cache. Z takim rozwiązaniem spotykamy się np. w procesorach Itanium 2. Kolejnym rozwiązaniem, które zresztą użytkownicy PC doskonale znają z procesorów Pentium 4 pod nazwą HyperThreading, jest współbieżna wielowątkowość. Polega ona na wprowadzaniu do potoku wykonawczego procesora dwóch (lub więcej) niezależnych wątków programu i równoległym ich wykonywaniu przez dostępne akurat jednostki wykonawcze. Współbieżna wielowątkowość jest rozwiązaniem pozwalającym na lepsze wykorzystanie jednostek wykonawczych w rozbudowanych procesorach superskalarnych. W Pentium 4 sprawdziła się nieszczególnie głównie dlatego, że procesor ten bynajmniej nie dysponował nadmiarem jednostek wykonawczych.

Niestety, nawet najwydajniejsza architektura nie jest w stanie nic poradzić na to, że wykonywany kod musi odwoływać się do danych w pamięci RAM, a także na to, że zawarte w nim relacje często uniemożliwiają wykorzystanie architektury superskalarnej.

Popatrzmy na opublikowane przez Intela wyniki testów wykorzystania procesora (wykonane dla Itanium 2 „Montecito”). W zadaniach klasy workstation (benchmarki SPECfp i SPECint) uzyskiwany praktycznie średni współczynnik IPC (Instructions Per Clock) wynosi około 0,5, zaś w serwerowych aplikacjach biznesowych – około 0,15. Kompletna porażka, szczególnie jeśli weźmiemy pod uwagę, że teoretycznie Itanium wykonuje 3 instrukcje w jednym cyklu, a kod programów jest optymalizowany do takiego wykonywania już na etapie kompilacji!