Kilka razy pytaliście w komentarzach, w jakim stopniu są obciążone procesory podczas różnych testów wydajności, które regularnie przeprowadzamy. Jak sądzimy, te informacje nie pozwalają wyciągnąć wniosków, których niektórzy się spodziewają, ale i tak mogą być bardzo pouczające. Zarejestrowaliśmy obciążenie procesora Core i9-9900K podczas przykładowych testów wydajności.
Spis treści
Obserwowanie wykorzystania procesora jest popularnym sposobem amatorskiego diagnozowania problemów z oprogramowaniem. Niektórym nawet obserwowanie nakładki z programów typu MSI Afterburnera w trakcie gry sprawia większą przyjemność, niż zanurzanie się w wirtualnym świecie.
Dla każdego testu obciążenie procesora w czasie testu zależy nie tylko od procesora, ale również od prędkości i przepustowości pamięci. Jeśli wykonywane zadanie wymaga wspomagania przez GPU i odczytuje dane z nośnika danych, to także od wykorzystanej karty graficznej i SSD. W większości programów, które nie są benchmarkami oderwanymi od praktycznego użytkowania komputera, wykorzystanie procesora zależy też od danych wejściowych. Nawet jeśli jesteście właścicielami takiego samego procesora i wykorzystacie te same programy, zapewne zobaczycie nieco inne profile obciążenia, niż te, które zaraz przedstawimy.
To jeden z powodów, dla których taki eksperyment nie mówi nam prawie nic użytecznego o sprzęcie. Nie będziemy próbować wyciągać z niego daleko idących wniosków – mamy tylko nadzieję, że pozwoli Wam trochę lepiej zrozumieć co oznaczają wyniki testów procesorów przedstawianych na PCLabie.
Co i jak zarejestrowaliśmy
Użycie procesora to pojęcie tak samo złożone, jak sam procesor. Menedżer zadań w Windowsie oraz podobne programy (HWInfo, MSI Afterburner, top i htop w Linuksie...) traktują procesor logiczny jako używany, jeżeli jest stanie energetycznym C0.
Stany energetyczne G dotyczą całego peceta: G0 oznacza włączone zasilanie. S to różne stany uśpienia – na przykład komputer przełączony w stan wstrzymania jest w stanach energetycznych G1 i S3. Stany C dotyczą procesorów logicznych: C0 to pracujący rdzeń lub wątek, C1-C6 to różne stopnie oszczędzania energii. W ramach C0 wspólczesne procesory mają jeszcze kilkanaście lub kilkadziesiąt P-stanów, czyli stanów wydajności, oznaczających różne kombinacje częstotliwości taktowania i napięcia zasilania.
System operacyjny jest odpowiedzialny za przełączenie procesora logicznego w stan C1 lub niższy, jeśli nie ma dla niego żadnej pracy. Tylko w stanie C0 procesor może wykonywać instrukcje. Procesor przełącza się w stan C1, kiedy wydano mu instrukcje HALT lub MWAIT – wtedy czeka na przerwanie lub na zapisanie danych pod wskazany wcześniej adres. W innych C-stanach, zależnie od procesora, mniejsze lub większe części procesora mogą być wyłączone. Może zostać zatrzymany zegar, wyczyszczona i zapisana do RAM-u pamięć podręczna.
Oczywiście przebywanie w C0 nie oznacza, że procesor wykonuje użyteczną pracę. Można stworzyć program, który będzie cały czas wykonywał jakieś instrukcje, ale nie będzie posuwał żadnego algorytmu do następnego kroku.
W tym eksperymencie zarejestrowaliśmy czas, jaki procesor logiczny spędził w stanie C0. Za pomocą liczników wydajności – mechanizmu diagnostycznego wbudowanego w procesor – rejestrowaliśmy to od 2 do 5 razy na sekundę przez cały czas trwania przykładowych testów wydajności, dokładnie takich, jakie przeprowadzamy w recenzjach nowych procesorów. Ten sposób jest bardzo dokładny jeśli chodzi o liczbę mierzonych wydarzeń – ponieważ to sprzętowy mechanizm wbudowany w procesor, nie myli się i nie zatrzymuje, kiedy obciążenie procesora jest bardzo wysokie. W większości przypadków ma znikomy wpływ na wydajność w testowanych zadaniach, ale nie powinno się rejestrować zbyt często lub zbyt długo.
Poza czasem spędzonym w C0 zarejestrowaliśmy też ilość danych przekazywaną pomiędzy kontrolerem pamięci a pamięcią RAM. Odczyt i zapis są zsumowane na wykresie. Ta wielkość nie obejmuje ruchu pomiędzy rdzeniami a pamięciami podręcznymi, ale zawiera ruch pomiędzy urządzeniami przestrzeni IO a pamięcią w ramach DMA.
Wyniki przedstawimy na wykresach podobnych do tego:
100% wykorzystania CPU oznacza, że jeden procesor logiczny (wątek) spędził 100% czasu od ostatniego pomiaru w stanie energetycznym C0. Ponieważ użyliśmy 8-rdzeniowego, 16-wątkowego procesora Core i9-9900K, całkiem zapełniony wykres (1600%) oznacza całkowicie zajęty procesor – to samo, co w menedżerze zadań byłoby opisane „100%”. Każdy kolor oznacza inny wątek, zawsze ten sam; szerokość pasma jednego koloru reprezentuje stopień wykorzystania jednego procesora logicznego. Test wydajności zwykle zaczyna się między 15. a 30. sekundą na wykresie.
Dokładnie. Przykład praktyczny - niektóre emulatory, które mocniej siedzą na wydajności pojedynczego wątku, np. PCSX2. Użycie CPU, sporo poniżej 100%, a jednak OC potrafi sporo dać. I to nawet na zwykłym C2D.
Zresztą, w niektórych grach z przeszłości bywa podobnie.
Tutaj chyba za dobry przykład posłużyłby Crysis.
W GPU z mylnym odczytem 100% jest podobnie. Nawet więcej - są zastosowania, gdzie monitor odczytu obciążenia GPU błędnie pokaże 0% podczas zadania akceleracji jakiegoś zadania, np. narzędzia oparte o sieci neuronowe (chyba z OpenCL), podczas gdy GPU-Z dopiero pokaże takie obciążenie, lub statystyki zaawansowane w menadżerze.
Czasami sprawia to problem ze sprawdzeniem, czy akceleracja działa, czy nie.
Jedyna praktycznie przydatna rzecz z tego tekstu dla zwykłego śmiertelnika to chyba fakt, że czista rdzyniuff nic nie da, jeśli jeden wątek będzie zapchany, a reszta będzie na niego czekała, co dla zadziwiająco dużego grona osób wydaje się konceptem niemożliwym do zrozumienia.
Jak na tle użytych 'generatorów obciążenia' wypada FIRESTARTER?
https://tu-dresden.de/zih/forschung/projekte/firestarter
pwf to były wyizolowane ze starej wersji Firestartera funkcje AVX256, skompilowane osobno na własne potrzeby. Na procesorach Intela pwf = Firestarter. Dziś używam po prostu Firestartera.
Co do gier: nieprawda, że wszystkim chodziło o gry. Dyskusja m. in. pod recenzjami Threadripperów i Cascade Lake X dotyczyła nie-gier, a ten artykuł jest jej rozwinięciem.
Gry składają się z bardzo małych, bardzo podobnych do siebie zadań obliczeniowych, z których każde trzeba ukończyć w skali kilkunastu milisekund. Obserwowanie C-stanów w skali setek milisekund jest zupełnie bezużyteczne do diagnozowania wydajności w tym przypadku. Do profilowania wydajności gier używa się innych technik, a wyciąganie użytecznych wniosków jest znacznie trudniejsze, ale może kiedyś do tego wrócę.
Chwila moment. Choć będzie zgoła niezupełnie adekwatny przykład do tego o co Ci chodzi.
Jak masz stary soft jednowątkowy, ale nie jest całkowicie źle napisany, to utylizacja CPU w systemie rozkłada się mniej więcej równo po wątkach. Wtedy możesz odpalić podobną operację rozbitą na kilka procesów, i wykonasz ją kilka razy szybciej.
Do tej pory np. twórcy programów do batch konwersji PNG/JPG/MP3/FLAC tego nie rozumieją i nadal nie zwielokrotniają operacji.
Inna sprawa, że są softy, które potrafią obciążyć pierwszy wątek na 100%, ale to są rzadkie przypadki, i z reguły wymuszane ręcznie przez system. Np. tryb kompatybilności z Windows 98.
masz na myśli NVIDIA Nsight i AMD CodeXL (Radeon GPU Profiler)?