r   e   k   l   a   m   a
r   e   k   l   a   m   a

Spór o wydajność Ryzena – Windows i Linux były na niego niegotowe?

Strona główna AktualnościSPRZĘT

Premiera pierwszych modeli procesorów AMD Ryzen za nami, testowali je niemal wszyscy, na przeróżne sposoby. Zazwyczaj zainteresowani rozstrzygnięciem tej ważkiej kwestii – czy AMD dostarczyło coś, co może wreszcie rywalizować z procesorami Core Intela? Z tego co widzieliśmy i sami sprawdziliśmy, można powiedzieć już, że tak, w zasadzie dostarczyło. Czemu w zasadzie? Jak przekonaliśmy się, mamy do czynienia z produktem bardzo świeżym, momentami za bardzo świeżym, z którym aktualnie dostępne oprogramowanie nie współpracuje w zadowalający sposób.

Po zdjęciu embarga na wyniki testów, ze wszystkich stron zaczęły nadchodzić doniesienia o różnicach w wydajności między Ryzenami i ich konkurentami ze strony Intela, o nierównej pracy szczególnie w obciążeniach wielowątkowych, a czasem nawet o niezadowalających wynikach przy włączeniu taktowania Turbo. Narzekano też na kiepską wydajność w graniu przy rozdzielczościach 1080p. Zgłoszenia dotyczyły oczywiście głównie Windowsa 10 – dla innych wersji Windowsa nie było oficjalnego wsparcia, a Linux mało kogo obchodził.

W każdym razie to praca dyspozytora (schedulera) przy włączonej jednoczesnej wielowątkowości SMT (a właściwie dwuwątkowości, tak jak jest to w HyperThreadingu Intela) była wskazywana jako główny winowajca, i nie bez podstaw, co szczególnie widać było w benchmarkach gier – niektóre gry, takie jak Hitman czy Deus Ex: Mankind Divided potrafiły wyraźnie przyspieszyć po tym, jak SMT wyłączono. Zaczęto więc mówić o problemach z odróżnianiem rdzeni fizycznych i logicznych przez system Windows 10, pojawiła się nawet informacja, że Microsoft miał przyznać się do problemów i zapowiedział pomoc w rozwiązaniu usterek.

r   e   k   l   a   m   a

Związek sprzętu i oprogramowania to delikatna sprawa

Faktycznie, taki wpis na Twitterze pochodził z konta należącego do Microsoftu, ale nie znaczył wiele – ot po prostu wsparcie techniczne zareagowało typową łasicą na nieznany sobie bliżej problem, obiecując podjęcie działań. To wystarczyło mediom, by zinterpretować to jako oficjalne stanowisko obu firm.

Przywiązywanie szczególnej wagi do oficjalnych stanowisk też jednak nie prowadzi za daleko. Widać to po tym rzeczywistym stanowisku AMD, które można streścić jednym zdaniem – „nic się nie dzieje, idziemy dalej”. W blogowym wpisie na AMD Community przeczytać możemy, że AMD przeprowadziło własne badania w kwestii niepoprawnego działania dyspozytora wątków Ryzena w Windowsie 10 i doszło do wniosku, że dyspozytor działa poprawnie, wykorzystując logiczną i fizyczną konfigurację architektury. Tym wszystkim doniesieniom o niewłaściwym rozpoznawaniu topologii miała być winna przestarzała wersja programu Sysinternals Coreinfo.

Odrzucono także te wszystkie spostrzeżenia dotyczące różnic w wydajności między Windowsem 10 a Windowsem 7, utrzymując że nie mają one nic wspólnego z pracą dyspozytora, a co najwyżej z różnicami w architekturze obu systemów – i podkreślono że wiele aplikacji poprawnie wykorzystuje rdzenie i wątki w Ryzenie, inne zaś przy pewnych optymalizacjach mogą to osiągnąć.

Przy okazji dowiedzieliśmy się też, że czujnik temperatury tCTL w Ryzenie 1800X i 1700X zwraca oprogramowaniu zawyżone o 20°C odczyty (czyli procesor jest faktycznie chłodniejszy, niż raportuje oprogramowanie, i że aby uzyskać na Windowsie 10 najlepsze wyniki, należy przełączyć system ze zrównoważonego modelu zasilania na „Wysoką wydajność”. Tyle w oficjalnym stanowisku. Mało, jak na komunikat dla społeczności geeków i nerdów, którzy jednak chcieliby wyjaśnienia tego co obserwują, a nie stwierdzenia, że nie ma co wyjaśniać.

Ubuntu niezbyt gotowe na Ryzena

Wkrótce po naszych testach Ryzena 1800X na typowych gamingowych obciążeniach z Windowsem 10, mieliśmy okazję pobawić się nowym procesorem na Linuksie. Jasne, nie mamy farmy sprzętu takiej jaką ma Phoronix, odsyłamy na OpenBenchmarking.org wszystkich zainteresowanych dokładnymi wynikami dla konkretnych konfiguracji – jedyne, co z naszych (niedoskonałych metodycznie) eksperymentów wynikało… że za wcześnie na wyniki.

Zaczęliśmy standardowo, od Ubuntu 16.04 LTS, z kernelem 4.4. Działać, działa – ale jak? Benchmarki Phoronix Test Suite zwykle przeprowadzają trzy cykle testów, potem uśredniając wyniki. Dobre podejście, ale co zrobić w sytuacji, gdy wiele popularnych testów, w których liczba rdzeni odgrywa kluczową rolę (kompilacja kernela, operacje graficzne na bitmapach, transkodowanie wideo, archiwizacja) przynosiły w poszczególnych cyklach wyniki rozbieżne o nawet 40%, lub nawet kończyły się niepowodzeniem?

Aktualizacja Ubuntu do 16.04.2, czyli najświeższej wersji LTS z kernelem 4.8 niczego w tej kwestii nie zmieniła – niczego też zmienić nie mogła, w kwestii wsparcia dla Ryzena kernel ten (ani jego poprzednicy niczego nie przyniósł). Ten sam kernel wykorzystywany jest też w najnowszej stabilnej wersji 16.10. Dopiero Ubuntu 17.04 przynosi kernel 4.10 z łatkami dla nowych procesorów AMD. Wczesnej wersji testowej udało się jednak nam uruchomić na Ryzenie, zawieszała się wkrótce po starcie na testowej maszynie.

Ostatecznie nieco testów przeprowadziliśmy na najświeższej Fedorze Rawhide, z niestabilnym jeszcze kernelem 4.11. Jakie zmiany – benchmarki z wielowątkowością działały pięknie… gdy działały. Od Rawhide można oczekiwać wszystkiego poza stabilnością. Co jednak najważniejsze, różnice wyników w poszczególnych cyklach skurczyły się do kilku procent.

Wciąż jednak, ze względu na brak dobrego środowiska porównawczego, z ostateczną oceną działania Ryzena na Linuksie wstrzymać się należy do wydania stabilnych wersji najpopularniejszych dystrybucji z kernelem 4.10.

Linux wymagał zmian, a co z Windows 10?

Atutem opensource’owego oprogramowania jest to, że wiemy, co się z nim dzieje. Historia dostosowania Linuksa do nowej architektury AMD jest dość pouczająca. W pracach nad kernelem 4.10 pojawiły się trzy łatki, dotyczące tego, jak identyfikowane są wątki i rdzenie w systemie.

Pierwsza łatka pochodzi ze stycznia – i poprawia topologię rdzeni, które dostały w pewnym momencie straciły swoje własne identyfikatory, co popsuło strategię wątków na procesorach w architekturze Bulldozer, gdzie każdy wątek był traktowany tak, jakby był swoim oddzielnym rdzeniem. Powrócono więc do dostarczanej przez firmware numeracji.

Doprowadziło to jednak do znacznych opóźnień na Ryzenach – wątki były często niepoprawnie parowane na rdzeniach, nie było jak sprawić, by dwa wątki korzystające z tych samych danych i instrukcji były uruchamiane na tym samym rdzeniu. Mogły one współdzielić zasoby, to jednak oznaczało opóźnienia.

Druga łatka pojawiła się na początku lutego. Dodała ona mechanizm zarządzania wątkami, przypisujący je do rdzeni, na których działa już wątek korzystający z tych samych zasobów, aby zmiejszyć opóźnienia w komunikacji przez cache. Dyspozytor obsługując wielowątkowość w Ryzenie będzie więc wyznaczał nowy wątek wpierw w ramach w dostępnej jednostki obliczeniowej.

Zarazem jednak ta łatka, choć rozwiązywała problemy z działaniem na Bulldozerach, zawodziła w architekturze Zen. Tam bowiem identyfikatory wątków są inaczej raportowane systemowi, co powoduje, że dyspozytor gubił się w ich obsłudze, myląc wątki i rdzenie. Trzecia łatka, naprawiająca topologię wielowątkowości rdzeni Zen, rozwiązuje to w prosty sposób. Sprawdza, czy ma do czynienia z Ryzenem, a jeśli tak, to dzieli liczbę zgłoszonych wątków przez liczbę par na jednostce obliczeniowej, by uzyskać faktyczną liczbę rdzeni – a później oddaje tę informację dyspozytorowi.

Dlatego właśnie kernel 4.10 nie ma już najwyraźniej problemów z obsługą wielowątkowości SMT. Jak zachowuje się kernel NT w tej kwestii – to już tajemnica Microsoftu. Trudno jednak przypuszczać, by w erze Windowsa 7 przewidziano poprawnie architekturę Ryzen i przygotowano pod nią zachowanie dyspozytora.

Analogie mogą być fałszywe?

Oczywiście wnioskowanie na podstawie zmian w Linuksie o tym, co dzieje się w Windowsie może być bardzo zawodne. Mechanizmy i algorytmy wykorzystywane w dyspozytorach obu systemach nie są do siebie podobne. System Microsoftu stawia na priorytetowe planowanie z wywłaszczeniem i mocno rozrzuca procesy po dostępnych wątkach procesora, starając się zapewnić, że wątek o najwyższym priorytecie będzie zawsze działał – chyba że zostanie wywłaszczony przez wątek o jeszcze wyższym priorytecie czy skończy się mu czas.

W dodatku od czasów Windows 7 deweloperzy dysponują czymś, co nosi nazwę user-mode scheduling, i co pozwala samym aplikacjom tworzyć wątki i zarządzać nimi niezależnie od kernela. Jest to szczególnie owocne podejście dla aplikacji wykorzystujących wiele wątków, pozwala uniknąć opóźnień związanych z wywoływaniem dyspozytora Windowsa. To jednak oznacza, że problemy z wielowątkowością mogą być wprowadzane przez same aplikacje, a nie przez system – i niewykluczone, że tak właśnie było z tymi wszystkimi grami, które gubiły się przy włączonym SMT na Ryzenie.

Dyspozytor Linuksa bazuje tymczasem na konkretnych klasach o przyznanych im priorytetach. Klasy te mogą mieć swoje własne algorytmy zarządzania. Wybór zadania do uruchomienia zaczyna się od wybrania klasy o najwyższym priorytecie i znalezienia w niej zadania o najwyższym priorytecie. Wszystko to kontrolowane jest z poziomu kernela, choć użytkownik ma swobodę dobrania sobie algorytmu działania dyspozytora. Dzięki temu właśnie tak łatwo dostosować Linuksa do tak różnych urządzeń jak superkomputery i smartfony, to jednak też oznacza, że trudno jest optymalizować konkretne aplikacje (w tym gry) na takim poziomie, co w Windowsie.

Jedno tylko można więc obecnie powiedzieć z całkowitą pewnością. Ryzen to bardzo młoda architektura, cierpiąca na bolączki wieku niemowlęcego. Nie wcześniej niż za kilka miesięcy, po ustabilizowaniu się oprogramowania, będziemy mogli ostatecznie powiedzieć, jak się ma do od lat rozwijanej architektury Core Intela.

Na razie wydaje się nam jedno – w swoim zachowaniu jeden ośmiordzeniowy Ryzen ze swoimi modułami CCX (CPU Complex) przypomina bardziej dwugniazdkowe, dwuprocesorowe systemy serwerowe z Xeonami, niż te wielordzeniowe Haswelle-E czy Broadwelle-E w jednym gniazdku. Możliwe więc, że te obserwowane problemy z zarządzaniem wielowątkowością dotyczą nie tyle dyspozytora, ale komunikacji i przekazywania wątków między modułami CCX. Czy w takim razie Ryzeny nie powinny być traktowane bardziej jak architektura typu NUMA, dla systemów wieloprocesorowych?

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.   

Trwa konkurs "Ogól naczelnego", w którym codziennie możecie wygrać najnowsze maszynki systemowe Hydro Connect 5 marki Wilkinson Sword.

Więcej informacji

Gratulacje!

znalezione maszynki:

Twój czas:

Ogól Naczelnego!
Znalazłeś(aś) 10 maszynek Wilkinson Sword
oraz ogoliłaś naszego naczelnego!
Przejdź do rankingu
Podpowiedź: Przyciśnij lewy przycisk myszki i poruszaj nią, aby ogolić brodę.