felietony

Threadripper 3990X w Windowsie 10 Pro i Enterprise

18
18 lutego 2020, 10:09 Mateusz Brzostek

Wszystkie rzeczowe komentarze i uwagi zgłoszone redakcji traktuję poważnie. Podobnie jak Czytelnicy, śledzę najważniejsze inne publikacje poświęcone sprzętowi, o którym publikuję na PCLab.pl. Jak słusznie domyślił się jeden z komentujących, rzeczywiście już nie dysponuję Ryzenem Threadripper 3990X, ale w trakcie testów i następnego dnia bezpośrednio po nich zdążyłem zebrać dość danych. Test Ryzena 5 1600 AF nie pozwolił mi opublikować ich natychmiast, ale teraz mogę wrócić do tej sprawy.

Windows 10 Pro kontra Enterprise

Według najlepszego stanu mojej wiedzy Windows 10 Pro, Windows 10 Pro for Workstations i Windows 10 Enterprise nie różnią się w żaden sposób pod względem zarządzania procesorami, wątkami czy pamięcią. Jakiekolwiek różnice w wydajności – jeżeli występują – nie wynikają z edycji systemu, ale z różnych pobocznych czynników.

Przekonanie nie podparte dowodami w tym przypadku nie wystarcza, dlatego sprawdziłem, czy w kilku testach znajdę jakąś różnicę w wydajności pomiędzy Windows 10 Pro a Enterprise. Chciałem mieć pewność, że ewentualne różnice na pewno nie będą wynikały z działania mechanizmu turbo lub różnych technik oszczędzania energii, dlatego w tych testach taktowanie procesora było zablokowane na 3600 MHz, a taktowanie pamięci na DDR-3600. Ponieważ wszystkie rdzenie miały takie samo taktowanie, przytwierdzanie wątków do procesorów logicznych oznaczonych przez CPPC2 jako potencjalnie najszybsze nie miało znaczenia. Oba systemy były zaktualizowane do najnowszych kompilacji (18363.628); nie instalowałem żadnych dodatkowych opcjonalnych aktualizacji, a jedynie sterownik chipsetu AMD.

Nie udało mi się zreprodukować wyników przedstawionych przez redakcję AnandTech. Żaden test wydajności nie wykazał większej różnicy między edycjami Pro a Enterprise niż ta, która może naturalnie wystąpić pomiędzy kolejnymi powtórzeniami testu w tych samych warunkach.

Miałem przez pewien czas hipotezę roboczą: różnica w wydajności mogła być związana z wersją, nie edycją systemu Windows. Być może testy Windows 10 Pro wykonano na przywróconej z kopii zapasowej, niezaktualizowanej wersji Windows 10 1709 (Fall Creators Update z 2017 roku), co jest popularnym podejściem, a testy Windows 10 Enterprise – na współczesnej, aktualnej wersji 1909. Opublikowany przez AnandTech zrzut ekranu z menedżera zadań pokazujący Threadrippera 3990X jako 2 procesory w osobnych podstawkach bez wątpienia pochodził właśnie ze starej wersji Windowsa 10. 

Windows 10 1709 jest rzeczywiście średnio mniej wydajny. Gdyby taktowanie procesora nie było zablokowane, różnice w wydajności mogyłyby być jeszcze większe, bo Windows 1709 nie wykorzystuje wszystkich nowoczesnych technik sterowania taktowaniem i zasilaniem i nie przypisuje krytycznych wątków do rdzeni osiągających najszybsze taktowanie. Oczywiście to wszystko tylko przypuszczenia – dokładnego wyjaśnienia wyników testów przedstawionych na AnandTech możecie oczekiwać tylko od redakcji AnandTech.

Oczywiście pomiędzy Windowsem Pro, Pro for Workstations a Enterprise są inne różnice, ale obecnie nie powinny mieć znaczenia nawet dla użytkownika Threadrippera 3990X:

  • Pro obsługuje maksymalnie 2 procesory (nie grupy procesorów) i 128 rdzeni (nie wątków), Pro for Workstations oraz Enterprise – 4 procesory i do 256 rdzeni, 
  • Pro obsługuje do 2 TB pamięci RAM, a Pro for Workstations i Enterprise do 6 TB pamięci, również nieulotnej, takiej jak Intel Optane DCPMM.

Podobnie pomiędzy Windowsem a różnymi edycjami Linuksa jest sporo różnic w wydajności. Wiele programów dostępnych dla obu systemów działa szybciej pod kontrolą Linuksa, ale nie jest to regułą. W recenzjach „wielkich” procesorów na PCLabie (m. in. Threadripperów wszystkich generacji oraz 18-rdzeniowców Intela) znajdziecie kilka testów wydajności przeprowadzonych w systemach Linux. Naszym celem jest zwykle scharakteryzowanie sprzętu, a nie systemów operacyjnych; zainteresowanym dokładnymi porównaniami między systemami polecam portal Phoronix.

Przykład 1: Blender

Blender jest doskonałym przykładem programu, który nie był do niedawna przygotowany na grupy procesorów. Interfejs Blendera od dawna pozwala wybrać, ile wątków renderujących ma zostać uruchomionych. W systemie Windows ustawienie więcej niż 64 nie dawało żadnej praktycznej korzyści w poprzednich wersjach Blendera, między innymi w 2.80a, w której testowałem wcześniej. Oba zrzuty ekranu poniżej pochodzą z tego samego systemu (Windows 10 Enterprise 1909) i tego samego testu, ale z dwóch różnych wersji Blendera. Pierwszy z wersji 2.80a, drugi z 2.81:

Obie wersje Blendera domyślnie proponują renderowanie za pomocą 64 wątków. Ręczne ustawienie 128 wątków w wersji 2.80a powoduje, że rzeczywiście odpowiednio dużo wątków zostaje stworzonych, ale wszystkie są przypisane do połowy procesora, i to w głupi sposób: do 64 procesorów logicznych należących do 32 rdzeni. Nie trzeba zmieniać nic w systemie operacyjnym, wystarczy użyć nowej wersji programu przygotowanej na więcej niż 1 grupę procesorów.

Przykład 2: Stockfish i pychb

Test symulacji szachowych wykonuję za pomocą przygotowanego przez siebie miniprogramu pychb oraz oficjalnej kompilacji silnika Stockfish. Pychb zastępuje program szachowy kompatybilny z interfejsem UCI: służy tylko do wykrywania liczby wątków i rodzaju procesora, zlecania zadania silnikowi szachowemu, monitorowania jego wydajności i mierzenia czasu. Stockfish jest przygotowany na grupy procesorów od ok. 2016 roku, ale mój program nie był. Niezmodyfikowana wersja pychb wykrywa 64 wątki i uruchamia silnik Stockfish z 64 wątkami, ale bez modyfikowania koligacji. Ponieważ Stockfish bierze pod uwagę grupy procesorów, może „wybierać” spośród wszystkich 128 procesorów logicznych w tej maszynie. Z kolei scheduler Windowsa bierze pod uwagę SMT, i 64 wątki zostają przypisane do co drugiego procesora logicznego. Dzięki temu każdy wątek Stockfisha ma dla siebie cały jeden rdzeń Threadrippera, co daje najlepszą wydajność. Stockfish uruchomiony na 3990X w ten nieoptymalny sposób jest i tak o ok. 30% wydajniejszy od uruchomionego również z 64 wątkami na 3970X. Stockfish uruchomiony w poprawny sposób (z liczbą wątków wybraną automatycznie albo określoną ręcznie na 128) jest o 55% wydajniejszy na 3990X.

Te przykłady powinny pokazywać, że:

  • Grupy procesorów nie są tym samym, co domeny NUMA. Grupy procesorów są cechą specyficzną dla Windowsa, a konfiguracja NUMA jest cechą sprzętu zupełnie niezależną od oprogramowania uruchomionego na nim.
  • System operacyjny nie sprawi, że wydajność w małowątkowych zadaniach zacznie się automatycznie skalować do ogromnej liczby wątków
  • Aby program wykorzystywał procesory logiczne z więcej niż jednej grupy procesorów w Windows, musi być odpowiednio zmodyfikowany albo przed kompilacją (jak Stockfish i Blender) albo w czasie rzeczywistym (np. za pomocą groupextend).

Nieustanna czujność

Komentarze pojawiające się pod wieloma tzw. „premierowymi” testami (czyli takimi, które są publikowane jednocześnie przez wiele publikacji internetowych) dowodzą, jak wielu Czytelników PCLaba czyta artykułyWłaściwie to nie czyta, tylko przegląda, i nie całe artykuły, ale przynajmniej podsumowania i najbardziej jadowite komentarze... poświęcone temu samemu sprzętowi jednocześnie na kilku portalach, zwykle anglojęzycznych. To bardzo dobrze – cieszę się z tego i piszę to całkowicie poważnie. Poziom dziennikarstwa sprzętowego jest dziś wysoki głównie właśnie dlatego, że można łatwo sięgnąć po wiele różnych publikacji na ten sam temat. Jeśli portal A przetestuje jakiś sprzęt w 10 zastosowaniach, portal B w 10 innych zastosowaniach, i tak dalej, czytelnik po przeczytaniu wszystkich publikacji ma szansę mieć bardziej kompletną wiedzę o czymś nawet niż autorzy poszczególnych publikacji. To również w pewien pośredni sposób wyrównuje poziom publikacji w niepowiązanych portalach, bo czytelnicy uczą się z jednych publikacji, czego powinni wymagać od innych.

Niestety nie wystarczy przeglądanie artykułów albo najlepiej ocenianych komentarzy. Trzeba poświęcić trochę uwagi – jesli nawet nie po to, żeby przeczytać cały artykuł, to przynajmniej upewnić się, czy jest w nim informacja, której poszukujecie. Jak sądzę, druga strona testu Threadrippera 3990X wyjaśnia dobitnie, że domeny NUMA nie są tym samym, co grupy procesorów; że do wykorzystania procesorów z dwóch grup przez program skompilowany dla Windowsa potrzebna jest modyfikacja programu, a nie systemu operacyjnego; że testy procesorów są wykonywane pod kontrolą Windowsa 10 Pro. Na stronie warunki testu podajemy więcej przydatnych informacji o testach, również takich, które inne portale uważają za nieistotne lub celowo ukrywają. Oczekujcie tego samego lub więcej od każdego innego portalu o komputerach i od swojego ulubionego youtubera. Oskarżanie redakcji w komentarzach o zupełnie przeciwne rzeczy pokazuje tylko, że autor komentarza więcej czasu poświęca na narzekanie, niż na czytanie.

Przeczytanie żadnego jednego artykułu, czy to na AnandTechu czy na PCLabie, nie daje kompletu wiedzy i pewności, że nigdzie nie wystąpiła pomyłka. Warto sięgać nie tylko do różnych artykułów, ale również do nieprzetrawionych, źródłowych informacji. Wątpcie we wszystko, weryfikujcie wszystko, czytajcie jak najwięcej – szczególnie, jeśli to czytanie nic nie kosztuje!

aszuZobacz profil
Poziom ostrzeżenia: 0%
aszu2020.02.18, 10:35
19#1
Pięknie i rzeczowo wytłumaczone - szacunek za profesjonalizm.
AdolphZobacz profil
Poziom ostrzeżenia: 0%
Adolph2020.02.18, 11:26
11#2
Popieram podsumowanie :)
DaviMZobacz profil
Poziom ostrzeżenia: 0%
DaviM2020.02.18, 11:53
Ocena: ********** (10/10).
anemusZobacz profil
Poziom ostrzeżenia: 0%
anemus2020.02.18, 12:08
-12#4
Tomshardware potwierdził, że różnice występowały przed 14 stycznia gdy pojawiła się poprawka do Windows 10 Pro.
AMD coś belkocze o rekomendowanej wersji systemu ale testy mimo, że NDA puściła je dopiero 7 lutego powstały dużo wcześniej. Sample by dotrzeć do wszystkich krążyły zapewne jeszcze przed premierą 7 stycznia. Najwięksi jak anandtech mieli je pewnie pierwsi i nie było możliwości by przetestowali je na dostosowanej wersji W10 Pro.
Tak więc AMD pojechało po bandzie w swoim komunikacie zarzucającym nierzetelność testujacym. Nie po raz pierwszy.
Edytowane przez autora (2020.02.18, 12:10)
czolgista778Zobacz profil
Poziom ostrzeżenia: 0%
czolgista7782020.02.18, 12:10
14#5
Jesli Anand testowal 3990X na 3 letnim buildzie to praktycznie jedna recka stracili cala rzetelnosc. Jedynym wytlumeczeniem byloby to ze oplacil ich Intel...
CaroozoZobacz profil
Poziom ostrzeżenia: 0%
Caroozo2020.02.18, 12:11
Owszem, czytamy na najróżniejszych portalach, i takie niuanse mają - jak widać - duże znaczenie.
NamonakiZobacz profil
Poziom ostrzeżenia: 0%
Namonaki2020.02.18, 12:19
a ludziom trzeba dalej tłumaczyć w komentarzach że Win API za pomocą którego tworzy się watki jest jednolite w ramach jednej wersji (generacji) Windows :D
chociażby funkcja CreateThread https://docs.microsoft.com/en-us/windows/w...pi-createthread
'Creating Threads' w dokumentacji MS
https://docs.microsoft.com/pl-pl/windows/w...reating-threads
KenjiroZobacz profil
Poziom ostrzeżenia: 0%
Kenjiro2020.02.18, 13:46
10#8
Namonaki @ 2020.02.18 12:19  Post: 1234279
a ludziom trzeba dalej tłumaczyć w komentarzach że Win API za pomocą którego tworzy się watki jest jednolite w ramach jednej wersji (generacji) Windows :D

Ale co to ma wspólnego ze schedulerem, w którym MS grzebie, grzebie i poradzić sobie nie może? Swoją drogą za Linuksem jest dekadę lub więcej...
darkmartinZobacz profil
Poziom ostrzeżenia: 0%
darkmartin2020.02.18, 22:06
Aplikacje pisane w .Net mają plik konfiguracyjny.
Z tego co czytałem, to po ustawieniu odpowiednich parametrów, wątki będą także tworzone nie tylko w pierwszej grupie. Można to prosto przetestować na aplikacjach dot netowych.
Problem różnej wydajności wersji Pro i Ent, był analizowany przez inne portale i wniosek jest taki, że wynikało to z różnych wersji kompilacji.
Fajnie było by wziąć serwerowego EPYC Rome i zobaczyć ile daje szerszy kontroler pamięci. Niestety to są takie ciekawostki, które raczej w polsko języcznych portalach nie będą zaspokojone.

<configuration
<runtime>
<gcServer enabled='true'/>
<GCCpuGroup enabled='true'/>
<Thread_UseAllCpuGroups enabled='true'/>
</runtime>
</configuration>
Edytowane przez autora (2020.02.18, 22:13)
lolek.oloZobacz profil
Poziom ostrzeżenia: 0%
lolek.olo2020.02.19, 16:04
Po prostu BRAWO. To się nazywa profesjonalne podejście. Świetny felieton. Jak najwięcej takich poproszę :)
Zaloguj się, by móc komentować
1