artykuły

AMD Ryzen Threadripper – technikalia [AKTUALIZACJA]

Nietypowa budowa

119 20 sierpnia 2017, 09:00 Mateusz Brzostek

Procesory Ryzen Threadripper mają specyficzną budowę, która wpływa na ich wydajność i możliwości konfiguracji przez użytkownika. Sprawdziliśmy szczegóły i działanie dwóch trybów dostępu do pamięci: UMA i NUMA, a także trybu gracza (dodaliśmy #4 stronę!)

Spis treści

W teście procesorów Threadripper nie mogliśmy wyczerpać wszystkich interesujących zagadnień, które ich dotyczą. Możemy to nadrobić w tej publikacji. Na początek opiszemy dwa tryby dostępu do pamięci operacyjnej (RAM), które można wykorzystać na platformie TR4, oraz tryb gracza. W najbliższych dniach dodamy na dalszych stronach więcej informacji technicznych, a także praktycznych obserwacji.

 

SMP i NUMA – czyli jak zbudować komputer z wielu procesorów

Dawno temu komputery były proste: miały jeden procesor, podłączony magistralą równoległą do kontrolera pamięci, do którego z kolei była podłączona pamięć operacyjna. Pewnego dnia ktoś wpadł na pomysł, żeby w jednym systemie umieścić więcej procesorów. Wymyślono różne sposoby ich łączenia, ale najlepszym okazała się konfiguracja SMP – Symmetric Multiprocessing. Symetria w nazwie oznacza, że wszystkie procesory mogą wykonywać te same rodzaje zadań i że mają taką samą pozycję – żaden nie jest traktowany priorytetowo przez system operacyjny ani inne części komputera, na przykład kontroler pamięci.

SMP to bardzo stara technika, pierwszy raz zastosowana w komputerze Burroughs B-825 z 1962 roku – znacznie poprzedza zatem nawet architekturę x86. Jednak najlepiej znanym nam przykładem SMP są pierwsze wieloprocesorowe komputery z procesorami x86. Możliwość pracy w wieloprocesorowej konfiguracji miały Pentium II Xeon (tak, Xeon nie był wtedy oddzielną marką) w 1998 roku, u AMD zaś – Athlony MP w 2001 roku. Schemat takiego systemu jest prosty i pokazuje równorzędność procesorów:

Schemat systemu SMP

Źródło: Ferrucio Zulian, Wikipedia, CC-BY-SA 3.0 

W przedstawionym schemacie łatwo rozpoznać anatomię systemu z kilkoma Pentium III Xeon, jednym dwurdzeniowym Pentium Extreme Edition, albo nawet Core 2 Quad. Procesory wraz z pamięcią podręczną są podłączone do magistraliMagistrala różni się od łącza tym, że może być do niej podłączonych wiele urządzeń. FSB i IDE są magistralami, ale na przykład PCI Express albo SATA – łączami punkt-punkt, które zawsze łączą tylko dwa urządzenia. FSB (system bus). Do tej samej magistrali są podłączone: arbiter, kontroler pamięci (te dwie funkcje realizował kiedyś jeden układ scalony – mostek północny) i kontroler I/O (mostek południowy).

W całym komputerze jest tylko jeden kontroler pamięci i dla każdego procesora jest on tak samo odległy – transfer danych z pamięci do dowolnego procesora odbywa się z takim samym opóźnieniem i taką samą przepustowością.

Odkąd kontroler pamięci zintegrowano w procesorze (pierwszy raz w DEC Alpha 21364, potem w Athlonach 64, dziś we wszystkich popularnych procesorach), łączenie dwóch lub więcej procesorów stało się bardziej skomplikowane.

Co to jest architektura NUMA

W systemie z kilkoma procesorami ze zintegrowanymi kontrolerami pamięci cała pamięć operacyjna należy do jednej przestrzeni adresowej. Pojemność RAM-u podłączonego do wszystkich kontrolerów pamięci jest połączona i dla oprogramowania jednolita. Jednak dostęp do pamięci nie jest jednolity – dane napływają szybciej, jeśli są umieszczone w części pamięci podłączonej do tego procesora, który o nie prosi. Spójrzmy na przykład na schemat blokowy platformy z procesorami AMD FX-70:

Schemat systemu SMP-NUMA

Dla programu działającego na którymś z dwóch rdzeni procesora na górze diagramu dostęp do lokalnej pamięci (po niebieskiej trasie) jest szybszy niż do pamięci podłączonej do drugiego procesora. Ponieważ dane trzeba przesłać przez dodatkowy pośredniczący interfejs, w tym przypadku łącze HyperTransport, opóźnienie w dostępie do odległej pamięci zawsze jest większe, a przepustowość zależy od przepustowości tego pośredniczącego interfejsu. 

Ta sama niejednolitość pamięci dotyczy wszystkich współczesnych wieloprocesorowych maszyn, niezależnie od producenta i architektury. Taką architekturę pamięci nazwano NUMA – Non Uniform Memory Access. Zauważmy, że w takiej architekturze procesory nadal mają równy priorytet i żaden z nich nie jest uprzywilejowany – wciąż mamy do czynienia z SMP. Żeby odróżnić „tradycyjne” SMP z jedną pulą pamięci od SMP-NUMA z równorzędnymi procesorami, dawne systemy zaklasyfikowano jako UMA – Uniform Memory Access (jednolity dostęp do pamięci).

NUMA kontra klaster obliczeniowy

Klaster obliczeniowy złożony z osobnych komputerów połączonych siecią LAN (albo specjalnymi łączami, takimi jak InfiniBand) też ma wiele równorzędnych procesorów, z których każdy ma własną pulę pamięci. Architektura NUMA ma nad nim istotną przewagę: w takim komputerze jest tylko jedna przestrzeń adresowa. Żadnych danych nie trzeba duplikować, wszystkie procesory pracują na jednym obszarze pamięci, a zawartość ich pamięci podręcznych jest zgodna. Programy mogą wykorzystać tyle pamięci operacyjnej, ile w sumie zainstalowano w całej maszynie.

Teoretycznie można potraktować klaster obliczeniowy z osobnych komputerów jako maszynę NUMA – ale tylko w ramach wirtualnej przestrzeni adresowej systemu operacyjnego, który na nim działa. Procesory i tak muszą tłumaczyć adresy wirtualne na fizyczne.

NUMA z punktu widzenia oprogramowania

Jeśli system operacyjny jest zgodny z NUMA, umie wydzielić obszary wspólnej przestrzeni adresowej i przypisać do nich poszczególne procesory. Taka grupa procesorów i lokalnej dla nich pamięci operacyjnej stanowi osobną domenę NUMA, a w komputerze może być wiele takich domen.

Ponieważ to system operacyjny zarządza podziałem przestrzeni adresowej na strony i przydzielaniem ich programom, może zadbać o to, żeby dane należące do programu były przechowywane w pamięci najbliższej temu rdzeniowi, który wykonuje dany program.

System operacyjny nie wie, co dokładnie robią działające w nim programy, i nie może dostosować alokacji pamięci bardziej szczegółowo. Jeżeli program potrzebuje więcej pamięci, niż jest dostępne w lokalnej puli, system zacznie mu przydzielać pamięć z odległej puli. Wtedy mały segment ważnych, często używanych danych może skończyć w odległej pamięci – choć większą wydajność zapewniłoby umieszczenie go w lokalnej pamięci o małym opóźnieniu. Żeby można było osiągnąć najwyższą wydajność w komputerze o architekturze NUMA, nie tylko system operacyjny, ale również oprogramowanie użytkowe musi brać pod uwagę topologię pamięci i procesorów. Windows udostępnia funkcje pozwalające programom zidentyfikować domeny NUMA i przypisać procesy i wątki do konkretnych domen (patrz dokumentacja NUMA w Windows).

Wszystkie nowoczesne systemy operacyjne są zgodne z NUMA bez ograniczeń licencyjnych: Windows 7 i nowsze, Linux z jądrem 3.8 lub nowszym, FreeBSD 11.0 i nowsze. Warto zauważyć, że Windows XP i Vista nie są zgodne z NUMA – w zależności od BIOS-u/UEFI komputera albo nie będą działać, albo będą traktować całą przestrzeń adresową jako jednolitą.

Strona:
KiliKiliZobacz profil
Poziom ostrzeżenia: 0%
KiliKili2017.08.20, 09:17
-30#1
Po przeczytaniu artykułu doszedłem do wniosku ,że w obecnej sytuacji jeśli ktoś chce zainwestować w AMD to najlepiej kupić 1900X ,i tak jak SB na którym jeszcze siedzę starczy na kilka lat...
duda007Zobacz profil
Poziom ostrzeżenia: 0%
duda0072017.08.20, 09:25
43#2
No I takie artykuły to ja lubię! Co prawda zagraniczne portale już wspominały o tym, tak samo osoby w komentarzach tutaj pod innymi artykułami, nie mniej szacun za podjęcie tematu!
barwniakZobacz profil
Poziom ostrzeżenia: 0%
barwniak2017.08.20, 09:26
-32#3
'Jak zwykle świat oprogramowania nie jest gotowy na postęp w architekturze PC.'
Świat oprogramowania, nie będzie optymalizował pod niszowy produkt.

AMD jak zwykle przed szereg. 3dnow, CPU 64bit. Jedyne co im wyszło na czas nie licząc R7, to kontroler RAM w CPU.
A infinity fabric, jak widać nie takie infinity.
RubasznyRumcajsZobacz profil
Poziom ostrzeżenia: 0%
RubasznyRumcajs2017.08.20, 09:36
OIDP zwykle pentiumy i athlony tez mogly pracowac w dwusystemowej konfiguracji.
celerony na pewno (te stare) mogly to robic. Pentiumy Pro tez- widzialem maszynke- oidp- 8 procesorowa z calymi (ponownie, oidp) 256mb pamieci :)
athlony mp to byla oddzielna linia gdy w zwyklych obcieto mozliwosc pracy w smp.
barwniakZobacz profil
Poziom ostrzeżenia: 0%
barwniak2017.08.20, 09:44
-5#5
RubasznyRumcajs @ 2017.08.20 09:36  Post: 1089603
OIDP zwykle pentiumy i athlony tez mogly pracowac w dwusystemowej konfiguracji.
celerony na pewno (te stare) mogly to robic. Pentiumy Pro tez- widzialem maszynke- oidp- 8 procesorowa z calymi (ponownie, oidp) 256mb pamieci :)
athlony mp to byla oddzielna linia gdy w zwyklych obcieto mozliwosc pracy w smp.


Jasne
Gigabyte GA-6VXD7, ABIT VP6, Acorp 6A815EPD, ABIT BP6
HΛЯPΛGŌNZobacz profil
Poziom ostrzeżenia: 0%
HΛЯPΛGŌN2017.08.20, 09:52
20#6
Artykuł pierwsza klasa. Powinno być więcej takich technicznych zagadnień.
mbe2017.08.20, 09:55
Dobry art. Brakuje takich w polskich internetach.
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842017.08.20, 09:59
39#8
barwniak @ 2017.08.20 09:26  Post: 1089601

Świat oprogramowania, nie będzie optymalizował pod niszowy produkt.

AMD jak zwykle przed szereg. 3dnow, CPU 64bit. Jedyne co im wyszło na czas nie licząc R7, to kontroler RAM w CPU.
A infinity fabric, jak widać nie takie infinity.

1. oczywiście, że developerzy będą optymalizować pod NUMA, bo nawet intel nie może ciągle powielać rdzeni w monolitycznym układzie
2. 3DNow! było bardzo ważnym naciskiem na intela, K6-III potrafiło w niektórych grach dogonić Pentium II Klamath (sterowniki nv i 3dfx z optymalizacjami 3DNow! oraz wsparcie w grach). Intel musiał zareagować i tylko dzięki temu masz SSE.
3. Intel nie zamierzał w ogóle rozszerzać x86 do 64bitów, ich oczkiem w głowie była architektura 64bitowa którą mieli sporo przed opteronami, czyli IA-64 (Itanium). Zatem jakie wyjście przed szereg z 64bit? Żadnego. A to, że zrobili sami 64bitowe x86 to powinieneś po stopach całować biorąc pod uwagę jakim niewypałem Itanium się okazało.
mbe2017.08.20, 10:21
-15#9
Promilus1984 @ 2017.08.20 09:59  Post: 1089610
barwniak @ 2017.08.20 09:26  Post: 1089601

Świat oprogramowania, nie będzie optymalizował pod niszowy produkt.

AMD jak zwykle przed szereg. 3dnow, CPU 64bit. Jedyne co im wyszło na czas nie licząc R7, to kontroler RAM w CPU.
A infinity fabric, jak widać nie takie infinity.

1. oczywiście, że developerzy będą optymalizować pod NUMA, bo nawet intel nie może ciągle powielać rdzeni w monolitycznym układzie
2. 3DNow! było bardzo ważnym naciskiem na intela, K6-III potrafiło w niektórych grach dogonić Pentium II Klamath (sterowniki nv i 3dfx z optymalizacjami 3DNow! oraz wsparcie w grach). Intel musiał zareagować i tylko dzięki temu masz SSE.
3. Intel nie zamierzał w ogóle rozszerzać x86 do 64bitów, ich oczkiem w głowie była architektura 64bitowa którą mieli sporo przed opteronami, czyli IA-64 (Itanium). Zatem jakie wyjście przed szereg z 64bit? Żadnego. A to, że zrobili sami 64bitowe x86 to powinieneś po stopach całować biorąc pod uwagę jakim niewypałem Itanium się okazało.

Każdy wie że barwniak to PRowiec intela więc nie ma co sie nad nim pastwić.
dapeZobacz profil
Poziom ostrzeżenia: 0%
dape2017.08.20, 10:21
-5#10
'Przykład Total War: Warhammer pokazuje, że w XXI wieku nie wystarczy programować wielowątkowo, trzeba to jeszcze robić z głową. Ta gra zwykle zyskuje na wielowątkowych procesorach, ale nie bierze pod uwagę tego, że zamiast tworzyć więcej i więcej wątków, lepiej stworzyć mniej, jeżeli dzięki temu będą miały zapewnioną lepszą komunikację między sobą i z pamięcią RAM.'

No i co jeszcze jako programistu softu wielo-wątkowego mam brać pod uwagę ? Jak są dostępne wątki to je wypełniam, nie będę robił ifa na każdą chorą architekturę, na to że 0,5 z 4GB VRAM może być wolniejsze, że połowa cachu w czymś może być wolniejsza, że uma, numa, sruma... bo koszty wytworzenia i utrzymania softu wzrosną kilkukrotnie. Zazwyczaj wykrywam ilość wątków w systemie i na podstawie numerka odpalam ilość workerów wykonujących zadania równolegle. Nikt mnie nie zmusi do ifowania w zależności od architektury bo doprowadzi to do niesamowitych komplikacji wewnątrz samego programu (zmienna ilości kanałów komunikacji między wątkami, wywłaszczenia, race conditions, pewnie jeszcze warunkowanie tylko tam gdzie dana architektura jest wolniejsza). Do tego część softu wymaga bardzo mocnej komunikacji między wątkami - nie da się tego zmienić ani obejść - jeśli twórcy architektury godzą się, z tym że ich twór będzie wolniejszy w niektórych zastosowaniach - niech i tak będzie, ale nie zrzucajmy na developerów winy za niedostatki architektury. Ciągle winni developerzy, brak optymalizacji, bugi a środowiska w których my musimy pracować to jedno wielkie bagno, jeszcze bardziej potęgowane przez coraz większe różnice w architekturach.
Zaloguj się, by móc komentować
1