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

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

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

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

Przywiązywanie szczególnej wagi do oficjalnych stanowisk teżjednak nie prowadzi za daleko. Widać to po tym rzeczywistymstanowisku AMD, które można streścić jednym zdaniem – „nicsię nie dzieje, idziemy dalej”. W blogowym wpisie na AMDCommunity przeczytać możemy, że AMD przeprowadziło własnebadania w kwestii niepoprawnego działania dyspozytora wątkówRyzena w Windowsie 10 i doszło do wniosku, że dyspozytor działapoprawnie, wykorzystując logiczną i fizyczną konfiguracjęarchitektury. Tym wszystkim doniesieniom o niewłaściwymrozpoznawaniu topologii miała być winna przestarzała wersjaprogramu Sysinternals Coreinfo.

Odrzucono także te wszystkie spostrzeżenia dotyczące różnic wwydajności między Windowsem 10 a Windowsem 7, utrzymując że niemają one nic wspólnego z pracą dyspozytora, a co najwyżej zróżnicami w architekturze obu systemów – i podkreślono żewiele 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 temperaturytCTL w Ryzenie 1800X i 1700X zwraca oprogramowaniu zawyżone o 20°Codczyty (czyli procesor jest faktycznie chłodniejszy, niż raportujeoprogramowanie, 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, jakna 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ć.

Wkrótce po naszych testach Ryzena 1800X na typowych gamingowychobciążeniach z Windowsem 10, mieliśmy okazję pobawić się nowymprocesorem na Linuksie. Jasne, nie mamy farmy sprzętu takiej jakąma Phoronix, odsyłamy na OpenBenchmarking.org wszystkichzainteresowanych dokładnymi wynikami dla konkretnych konfiguracji –jedyne, co z naszych (niedoskonałych metodycznie) eksperymentówwynikał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 zwykleprzeprowadzają trzy cykle testów, potem uśredniając wyniki. Dobrepodejś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 zkernelem 4.8 niczego w tej kwestii nie zmieniła – niczego teżzmienić nie mogła, w kwestii wsparcia dla Ryzena kernel ten (anijego poprzednicy niczego nie przyniósł). Ten sam kernelwykorzystywany jest też w najnowszej stabilnej wersji 16.10. DopieroUbuntu 17.04 przynosi kernel 4.10 z łatkami dla nowych procesorówAMD. Wczesnej wersji testowej udało się jednak nam uruchomić naRyzenie, zawieszała się wkrótce po starcie na testowej maszynie.

Ostatecznie nieco testów przeprowadziliśmy na najświeższejFedorze 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ą. Cojednak najważniejsze, różnice wyników w poszczególnych cyklachskurczyły się do kilku procent.

Wciąż jednak, ze względu na brak dobrego środowiskaporównawczego, z ostateczną oceną działania Ryzena na Linuksiewstrzymać się należy do wydania stabilnych wersjinajpopularniejszych dystrybucji z kernelem 4.10.

Atutem opensource’owego oprogramowania jest to, że wiemy, cosię z nim dzieje. Historia dostosowania Linuksa do nowejarchitektury AMD jest dość pouczająca. W pracach nad kernelem4.10 pojawiły się trzy łatki, dotyczące tego, jakidentyfikowane 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łasneidentyfikatory, co popsuło strategię wątków na procesorach warchitekturze Bulldozer, gdzie każdy wątek był traktowany tak,jakby był swoim oddzielnym rdzeniem. Powrócono więc dodostarczanej 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łojak sprawić, by dwa wątki korzystające z tych samych danych iinstrukcji były uruchamiane na tym samym rdzeniu. Mogły onewspółdzielić zasoby, to jednak oznaczało opóźnienia.

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

Zarazem jednak ta łatka, choć rozwiązywała problemy zdziałaniem na Bulldozerach, zawodziła w architekturze Zen. Tambowiem identyfikatory wątków są inaczej raportowane systemowi, copowoduje, że dyspozytor gubił się w ich obsłudze, myląc wątki irdzenie. Trzeciałatka, naprawiająca topologię wielowątkowości rdzeni Zen,rozwiązuje to w prosty sposób. Sprawdza, czy ma do czynienia zRyzenem, a jeśli tak, to dzieli liczbę zgłoszonych wątków przezliczbę 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ówz 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.

Oczywiście wnioskowanie na podstawie zmian w Linuksie o tym, codzieje się w Windowsie może być bardzo zawodne. Mechanizmy ialgorytmy wykorzystywane w dyspozytorach obu systemach nie są dosiebie podobne. System Microsoftu stawia na priorytetowe planowanie zwywłaszczeniem i mocno rozrzuca procesy po dostępnych wątkachprocesora, starając się zapewnić, że wątek o najwyższympriorytecie będzie zawsze działał – chyba że zostaniewywłaszczony przez wątek o jeszcze wyższym priorytecie czy skończysię mu czas.

W dodatku od czasów Windows 7 deweloperzy dysponują czymś, conosi nazwę user-mode scheduling, i co pozwala samym aplikacjomtworzyć wątki i zarządzać nimi niezależnie od kernela. Jest toszczególnie owocne podejście dla aplikacji wykorzystujących wielewątków, pozwala uniknąć opóźnień związanych z wywoływaniemdyspozytora Windowsa. To jednak oznacza, że problemy zwielowątkowością mogą być wprowadzane przez same aplikacje, anie przez system – i niewykluczone, że tak właśnie było z tymiwszystkimi grami, które gubiły się przy włączonym SMT naRyzenie.

Dyspozytor Linuksa bazuje tymczasem na konkretnych klasach oprzyznanych im priorytetach. Klasy te mogą mieć swoje własnealgorytmy zarządzania. Wybór zadania do uruchomienia zaczyna sięod wybrania klasy o najwyższym priorytecie i znalezienia w niejzadania o najwyższym priorytecie. Wszystko to kontrolowane jest zpoziomu kernela, choć użytkownik ma swobodę dobrania sobiealgorytmu działania dyspozytora. Dzięki temu właśnie tak łatwodostosować Linuksa do tak różnych urządzeń jak superkomputery ismartfony, 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 nabolączki wieku niemowlęcego. Nie wcześniej niż za kilka miesięcy,po ustabilizowaniu się oprogramowania, będziemy mogli ostateczniepowiedzieć, jak się ma do od lat rozwijanej architektury CoreIntela.

Na razie wydaje się nam jedno – w swoim zachowaniu jedenośmiordzeniowy Ryzen ze swoimi modułami CCX (CPU Complex)przypomina bardziej dwugniazdkowe, dwuprocesorowe systemy serwerowe zXeonami, niż te wielordzeniowe Haswelle-E czy Broadwelle-E w jednymgniazdku. Możliwe więc, że te obserwowane problemy z zarządzaniemwielowątkowością dotyczą nie tyle dyspozytora, ale komunikacji iprzekazywania wątków między modułami CCX. Czy w takim razieRyzeny nie powinny być traktowane bardziej jak architektura typuNUMA, dla systemów wieloprocesorowych?