Test procesora AMD Ryzen Threadripper 2990WX. Mocarz o kryształowej szczęce

Omówienie rezultatów rozpocznę od wariantu jednowątkowego, tudzież dwuwątkowego w przypadku emulatora Dolphin oraz czynności projektowych w Blenderze, gdzie sytuacja jest nieco mniej skomplikowana niż w przypadku pozostałych testów. Mówiąc najprościej jak się da, wszędzie tam, gdzie specyficzna budowa, w postaci czterech jąder Zeppelin w konfiguracji NUMA, spośród których połowa z nich nie ma w ogóle swojej pamięci, nie przeszkadza pod kątem wydajnościowym przy ustawieniach fabrycznych, czy też przeszkadza w stopniu lekkim, osiągi prezentują się zgodnie z przewidywaniami. Mowa o poziomie zbliżonym do Ryzena 7 2700, podkręconego do 4 GHz - raz nieco lepiej, raz nieco gorzej, co zasadniczo pokrywa się z teoretycznymi maksymalnymi wartościami Turbo dla Ryzena Threadrippera 2990WX. Niemniej jednak zdarzają się też przypadki mniej korzystne. Wśród tych ostatnich należy wymienić Dolphina, przeglądarkę Mozilla Firefox, a także pomiary w viewportach - 3ds Max 2019 oraz Cinebench (OpenGL). O ile testy przeglądarkowe są w zasadzie sztuką dla sztuki bez większego praktycznego znaczenia, zaś zainteresowanych emulacją konsol Nintendo będzie raczej niewielu, to jednak spore problemy w zastosowaniach związanych z grafiką 3D są już niepożądane. W 3ds Maxie było tak źle, że nie miałem innego wyboru, jak przeprowadzić dodatkowe pomiary weryfikujące w konfiguracji 8C/16T (1x Zeppelin). Ich wyniki nie pozostawiają złudzeń, że z samym procesorem problemów nie było - to oprogramowanie (system Windows oraz pakiet od Autodesk) nie poradziło sobie z niecodzienną konfiguracją.

Ryzen Threadripper 2990WX okazał się procesorem o dwóch obliczach. Tym samym wymaga od potencjalnego nabywcy dodatkowych nakładów pracy, aby zniwelować znaczenie potencjalnych problemów, których - delikatnie mówiąc - nie brakuje.

O ilu już w przypadku testów jednowątkowych było jasne, że niespodziewane problemy z osiągami są dla 32-rdzeniowego mocarza od AMD chlebem powszednim, to jednak dopiero pomiary wielowątkowe okazały się prawdziwą jazdą bez trzymanki. Powodów było kilka. Jako pierwszy z nich można wymienić programy, które miały limit 32 wątków. Mowa o popularnej aplikacji do kompresji plików, 7-Zip, oraz wielofunkcyjnym odtwarzaczu plików dźwiękowych, m.in. z funkcją konwersji formatów audio - foobar2000. W obu przypadkach ograniczenie liczby wątków nie pozwoliło w pełni rozwinąć skrzydeł testowanemu CPU i w efekcie nieco lepiej sprawowały się ustawienia bez aktywnego SMT, gdzie system operacyjny miał trochę mniej spraw do "przemyśleń", aczkolwiek dysproporcje nie są duże. Kompilacja również nie okazała się być jednoznaczna w ocenie. Oczywiście w przypadku relatywnie małych projektów, jak x265, z oczywistych względów trudno liczyć na pełną utylizację wątków, więc pozycja Threadrippera 2. generacji nie jest zaskoczeniem. Za to kompilacja bibliotek Boost wypadła naprawdę solidnie, co ponownie nie powinno dziwić, gdyż jednostka była obciążona w 100%. Z drugiej strony, oprogramowanie Microsoftu nie poradziło sobie już tak dobrze. Ogólna wydajność wciąż stoi na wysokim poziomie, jednak zaskoczeniem na minus był fakt, że lepiej poradziła sobie konfiguracja z wyłączonym SMT - pomimo pełnego wykorzystania 64 wątków. Standardowy test enkodera x264 także nie był w stanie efektywnie wykorzystać więcej niż 32 procesorów logicznych, toteż w tym przypadku parametry 32C/32T również okazały się efektywniejsze. Różnica jest co prawda minimalna, ale należy ją odnotować.

Skoro już wspomniałem o konwersji wideo, to od razu wypadałoby przedstawić, jak sytuacja wygląda dla x265. Jest to test, który przygotowywałem specjalnie dla Ryzena Threadrippera 1950X, aby pokazać pełnię jego możliwości. Stąd wysoka rozdzielczość materiału wejściowego, a także odpowiednie parametry enkodowania, w tym dodatkowy pomiar przy presecie Fast, gdzie stopień obciążenia wątków jest możliwie wysoki. To wszystko oczywiście nie pozwoliło na pokazanie pełni możliwości 64-wątkowego kolosa, ale dużo do tego celu nie brakowało - mowa o 75-80% wykorzystania czasu procesora. Tak więc jeszcze trochę wydajności jest do wyrwania, ale już stosunkowo niewiele i aby tego dokonać, trzeba by się uciec do sztuczek w postaci konwersji dwóch plików jednocześnie, dbając przy tym o odpowiednią izolację enkoderów w domenach NUMA. Warto również podkreślić, że jest to test robiący solidny użytek z instrukcji AVX, stąd relatywnie niska pozycja procesorów AMD, które potrzebują przynajmniej dwukrotnie większej liczby rdzeni, w porównaniu do konkurentów spod znaku Intela, aby zapewnić porównywalną wydajność. Bardzo podobnie sytuacja wygląda w PrimeGrid, popularnym projekcie na platformie BOINC. Jeśli natomiast o rendering chodzi, to - skupiając się na dużych scenach (Domek/Ogród nocą w przypadku 3ds Maxa oraz Dom dla Blendera) - widać jak dłoni, że mocy jest dość dużo. Na ogół jednak trudno mówić o jakimś rewelacyjnym skalowaniu (chociaż źle wcale nie jest!), co nie powinno dziwić - wykorzystanie pamięci dla wymienionych scen jest wysokie, a w tym aspekcie główny bohater ma swoje za uszami, o czym pisałem już we wstępie, a także dwa akapity wcześniej.

Testy symulacyjne w 3DMarku niezbyt dobrze wykorzystują wiele wątków, stąd też nie dziwią mnie wyższe rezultaty przy parametrach 32C/32T. Różnice potrafią być całkiem spore, wystarczy popatrzeć na Fire Strike Ultra czy Sky Diver. W zasadzie jedynie Time Spy Extreme jest w stanie naprawdę porządnie obciążyć procesor, ale tutaj powtarza się sytuacja z HandBrake oraz PrimeGrid - intensywne wykorzystanie AVX mocno sprzyja jednostkom Intela. Z bardziej praktycznych rzeczy i projektu XANSONS, także i tutaj nie obyło się bez problemów. Mianowicie jeden WU (ang. work unit) wykonywał się bardzo długo przy aktywnych 64 wątkach, stąd krótszy czas wykonania dla wyłączonego SMT. Zysk z wielowątkowości symultanicznej, w tym konkretnym przypadku, jest jednak dość niewielki (około 10% dla porównania Core i5/i7 generacji Coffee Lake), więc nie tracimy zbyt wiele. Tradycyjnie konikiem AMD są zastosowania kryptograficzne, ale ponownie z małym haczykiem, którym jest dostępna przepustowość RAM. O ile Ryzen Threadripper 1950X mógł posiłkować się dystrybuowanym trybem pamięci operacyjnej, to jednak najwyższy model serii Colfax jest tego przywileju pozbawiony. Stąd też zaskakująco słabe wyniki dla przypadków, gdzie wykorzystywany jest algorytm AES - w szczególności dla szyfrowania z jego wyłącznym użyciem. Jeżeli więc ogólnie o wydajność chodzi, to trzeba powiedzieć, że chociaż potrafi być naprawdę rewelacyjna, to jednak liczba niespodziewanych przypadłości i mniejszych lub większych problemów jest równie wysoka, co nie jest optymistyczną wiadomością, biorąc pod uwagę cenę omawianego produktu.

Jeżeli o wspomniane niedogodności chodzi, to największych doświadczyłem podczas renderingu z wykorzystaniem 3ds Maxa oraz V-Raya. Zachowanie pakietu było bardzo nieprzewidywalne, a sam problem dotyczył początkowej fazy całego procesu - budowania "light cache". Typowo operacja ta powinna potrwać ~30 s, jednak w przypadku Threadrippera 2. generacji jej czas był czysto losowy. Zadanie potrafiło zamknąć się w połowie minuty, ale też potrwać i pięć minut, a to naprawdę solidny rozstrzał wydajnościowy. Co więcej, to pierwszy procesor, gdzie występowało takie zjawisko. Na dziesięć wykonanych prób tylko jedna była "poprawna",  o ile w ogóle można określenie to uznać za adekwatne. Co ciekawe, przy wyłączonym SMT rendering był już przewidywalny, chociaż oczywiście strata mocy jest znaczna. Oczywiście nie mówię, że moje dziesięć prób są reprezentatywnym wyznacznikiem odnośne tego, jaki procent renderów przebiega bez zakłóceń i w rzeczywistości wskaźnik ten może być większy lub mniejszy od ~10%. Nie wykluczam też, że być może istnieje proste rozwiązanie problemu. W każdym razie mnie nie udało się go odszukać. Nietypowe przebiegi zdarzały się również w 7-Zipie oraz HandBrake, gdzie czasy potrafiły być o kilkanaście, a nawet kilkadziesiąt (dla kompresji) sekund gorsze od "optymalnych". Ponownie sprawa była czysto losowa - albo próba się udała, albo nie. Ogólnie rzecz ujmując, Windows i cztery węzły NUMA, szczególnie w tak nietypowej konfiguracji, to raczej niezbyt szczęśliwe połączenie, które często wymaga dodatkowej gimnastyki, aby uporać się z nieprzewidzianymi przeciwnościami losu (czy raczej ścieżkami schedulera systemowego i/lub samych programów).