Jak Hone ocenia optymalizacje wydajności

Wiele ustawień komputera próbuje brzmieć przekonująco. Zmień klucz rejestru, wyłącz funkcję systemu Windows, dostosuj ustawienie i od razu nazwij to wzrostem FPS.

Dla Hone to za mało.

Zanim dodamy optymalizację, musimy zrozumieć, co zmienia, dlaczego może pomóc i jak ją przetestować. Jeśli nie potrafimy odpowiedzieć na te pytania, nie wdrażamy jej.

W skrócie

Każda optymalizacja Hone wymaga:

• Rzeczywistego problemu do rozwiązania
• Jasnego wyjaśnienia, co zmienia
• Mierzalnego celu
• Znanych zagrożeń
• Bezpiecznego sposobu wycofania zmiany
• Dowodów wystarczająco mocnych, aby uzasadnić zmianę
• Jasnego określenia, które systemy mogą na niej skorzystać

Zmiana nie musi pomagać każdemu komputerowi, ale musi mieć uzasadnienie i nie może tworzyć większego problemu niż ten, który rozwiązuje.

Na mniejszych ekranach ustaw fokus na ilustracji i przewijaj ją poziomo strzałkami lub gestem.

1. Zaczynamy od problemu

Zaczynamy od typowych problemów, które może zauważyć gracz, takich jak:

• Przycięcia spowodowane działaniem procesów w tle
• Niestabilne czasy renderowania klatek
• Wysokie opóźnienie sterowania
• Aktywność dysku powodująca zacięcia
• Opóźnienie sieci pod obciążeniem
• Aplikacje konkurujące z grą o procesor lub pamięć

Jeśli nie potrafimy opisać problemu, zmiana zostaje automatycznie odrzucona.

„To ustawienie istnieje” nie jest powodem, aby je zmieniać. „To ustawienie kontroluje zachowanie, które może powodować opóźnienia podczas gry” jest czymś, co możemy zbadać.

2. Rozumiemy, co zmienia dane ustawienie

Każda optymalizacja wymaga bezpośredniego wyjaśnienia.

Powinniśmy umieć odpowiedzieć:

• Na którą część systemu Windows wpływa?
• Jakie zachowanie zmienia się po zastosowaniu?
• Dlaczego może to wpływać na gry?
• Które systemy najprawdopodobniej na tym skorzystają?

Przykładem jest nasza zmiana koligacji urządzeń, która modyfikuje sposób przydzielania określonych zadań sprzętowych do rdzeni procesora. W niektórych systemach przeniesienie tych zadań może zmniejszyć rywalizację o zasoby i opóźnienia.

Nie dowodzi to, że zmiana zawsze pomaga, ale daje nam mechanizm do przetestowania.

Jeśli nie potrafimy wyjaśnić mechanizmu, traktujemy zmianę jako domysł.

3. Ustalamy ryzyko

Najpierw szukamy tego, co może pójść nie tak, a dopiero później wzrostu wydajności.

W zależności od zmiany optymalizacja może wpływać na:

• Stabilność
• Płynność wyświetlania klatek
• Opóźnienie sterowania
• Sterowniki i podłączone urządzenia
• Uruchamianie gier
• Zgodność z systemami ochrony przed oszustwami
• Zużycie energii i temperatury
• Aktualizacje systemu Windows

Niektóre zmiany łatwiej kontrolować niż inne. Ograniczenie aktywności w tle podczas gry jest łatwiejsze do cofnięcia niż modyfikowanie niskopoziomowego działania urządzenia.

Bardziej ryzykowna zmiana nie jest automatycznie odrzucana. Wymaga jednak silniejszych dowodów, węższego zakresu i niezawodnego sposobu wycofania.

Jeśli nie możemy bezpiecznie cofnąć zmiany, nie traktujemy jej lekko.

4. Określamy, co oznacza sukces

Nie każda optymalizacja ma zwiększać średnią liczbę FPS.

Zmiana może zamiast tego ograniczyć przycięcia, poprawić płynność klatek, obniżyć opóźnienie sterowania, zmniejszyć aktywność w tle lub ustabilizować wydajność sieci.

Dobieramy test do deklarowanego efektu:

• FPS i płynność: średnia liczba FPS, najniższe 1% i 0.1%, czasy klatek oraz przycięcia
• Opóźnienie: zmierzone opóźnienie komputera, czasy sterowników, obsługa przerwań lub planowanie procesora
• Pamięć masowa: opóźnienie odczytu i zapisu, czas odpowiedzi oraz zacięcia podczas wczytywania zasobów
• Sieć: ping, jitter, zachowanie pakietów i bufferbloat

Ma to znaczenie, ponieważ niewłaściwy pomiar może sprawić, że słaby wynik będzie wyglądał na sukces.

Zmiany sieciowej nie należy oceniać na podstawie FPS. Poprawy opóźnienia nie należy odrzucać tylko dlatego, że średnia liczba FPS się nie zmieniła. Wyższa średnia liczba FPS nie jest sukcesem, jeśli przycięcia stają się gorsze.

Na mniejszych ekranach ustaw fokus na ilustracji i przewijaj ją poziomo strzałkami lub gestem.

5. Przeprowadzamy kontrolowane testy

Wydajność komputera jest zmienna.

Wyniki mogą się zmieniać z powodu kompilacji shaderów, zadań systemu Windows, temperatur, aplikacji w tle, różnych map, warunków na serwerze, a nawet kierunku, w którym gracz patrzy podczas testu.

Kontrolujemy jak najwięcej czynników:

• Ten sam komputer i sprzęt
• Ta sama gra, mapa, scena, trasa lub powtórka
• Te same ustawienia graficzne
• Te same wersje systemu Windows i sterowników
• Ten sam plan zasilania
• Te same aplikacje w tle
• Ta sama metoda pomiaru i długość testu
• Ten sam limit FPS i ustawienia synchronizacji
• Te same warunki ponownego uruchomienia

Testujemy także tylko jedną zmianę naraz. Jeśli razem włączymy pięć zmian, nie będziemy wiedzieć, która pomogła lub spowodowała problem.

Jeden dobry przebieg nie wystarcza.

Dla każdego komputera wykonujemy test bazowy od 3 do 5 razy przed zastosowaniem zmiany. Następnie stosujemy zmianę raz, w razie potrzeby uruchamiamy komputer ponownie i wykonujemy ten sam test od 3 do 5 razy po zmianie.

Oznacza to, że każde porównanie przed i po obejmuje łącznie od 6 do 10 przebiegów na komputer. Powtarzanie testu pomaga uwzględnić normalną zmienność i wykryć wyniki zależne od kompilacji shaderów, pamięci podręcznej lub innych warunków tymczasowych.

Przed porównaniem wyników sprawdzamy, jak bardzo różnią się między sobą przebiegi bazowe. Zmianę uznajemy za poprawę tylko wtedy, gdy późniejsze wyniki przekraczają normalną zmienność bazową, a efekt pojawia się konsekwentnie w wielu przebiegach.

Jeśli wyniki przed i po są zbyt podobne, wniosek brzmi: „brak mierzalnej różnicy”.

Każda zmiana przechodzi ten sam proces, zanim wyciągniemy wniosek. Jeśli wynik nie utrzymuje się w powtarzanych testach, nie nazywamy go poprawą. W tym miejscu Hone odróżnia się od większości narzędzi optymalizacyjnych.

Na mniejszych ekranach ustaw fokus na ilustracji i przewijaj ją poziomo strzałkami lub gestem.

6. Porównujemy wynik z ryzykiem

Mierzalna poprawa nie zawsze jest warta wdrożenia.

Mały, powtarzalny zysk z mało ryzykownej zmiany może być przydatny. Ten sam zysk może nie uzasadniać zmiany, która mogłaby powodować awarie, przycięcia lub problemy z urządzeniami.

Analizujemy pełny wynik:

• Jak duża była poprawa?
• Czy się powtarzała?
• Czy poprawiła się stabilność czasów klatek?
• Czy zmniejszyło się opóźnienie?
• Czy pogorszył się inny wskaźnik?
• Czy system pozostał stabilny?
• Czy zmianę można cofnąć?
• Czy pomaga tylko na określonym sprzęcie lub w konkretnych grach?

Pytanie nie sprowadza się do tego, czy wzrosła jedna liczba. Korzyść musi uzasadniać zmianę.

7. Określamy, gdzie zmiana pomaga, a gdzie nie

Większość optymalizacji zależy od określonych warunków.

Zmiana może pomóc, gdy:

• Gra jest ograniczona przez procesor
• Aplikacje w tle konkurują z grą
• System ma skoki opóźnień sterowników
• Aktywność pamięci masowej powoduje zacięcia
• Procesor jest starszy lub ma mniej dostępnych zasobów
• Opóźnienie sieci rośnie, gdy połączenie jest obciążone

Nie oznacza to, że zmiana jest słaba.

Wolimy przedstawić konkretny wniosek, który możemy poprzeć, niż obiecać każdemu wzrost FPS.

8. Zachowujemy, zmieniamy lub odrzucamy

Każda optymalizacja kończy się jedną z trzech decyzji.

Zachowujemy

Zachowujemy ją, gdy:

• Mechanizm jest jasny
• Docelowy wskaźnik się poprawia
• Wynik się powtarza
• Ryzyko jest uzasadnione
• Zmianę można cofnąć
• Wiemy, gdzie należy jej używać

„Akceptowalne ryzyko” nie oznacza braku ryzyka. Oznacza, że możliwa wada jest ograniczona, zrozumiała i odwracalna.

Zmieniamy

Czasami pomysł jest dobry, ale implementacja nie jest gotowa.

Zmiana może poprawiać jeden wskaźnik, a pogarszać inny. Może wymagać ograniczenia do określonego sprzętu lub gier. Może też potrzebować lepszych ustawień albo bezpieczniejszego sposobu wycofania.

Pozytywny benchmark nie oznacza automatycznie, że wdrożymy zmianę.

Odrzucamy

Odrzucamy zmianę, gdy:

• Nie potrafimy wyjaśnić, co zmienia
• Wynik się nie powtarza
• Korzyść jest zbyt mała, aby miała znaczenie
• Powoduje niestabilność lub przycięcia
• Ryzyko problemów ze zgodnością jest zbyt wysokie
• Nie można jej bezpiecznie cofnąć
• Dowody nie potwierdzają deklarowanego efektu

Odrzucenie zmiany zawsze jest częścią procesu; porażką jest wdrożenie zmiany, która nie została potwierdzona.

Przykład: koligacja urządzeń

Przetestowaliśmy tę optymalizację zgodnie z metodą opisaną w artykule. Użyliśmy tej samej konfiguracji, scenariuszy i ustawień, wykonując pięć pomiarów przed zastosowaniem zmiany i pięć po niej. Wyniki pokazały niewielki wzrost średniej wydajności, z około 177 FPS do 182 FPS. Średni czas klatki i zmierzone opóźnienie komputera również nieznacznie się poprawiły.

Zamiast przedwcześnie twierdzić, że „ta zmiana zwiększa FPS”, doszliśmy do następującego wniosku:

Na tym systemie zmiana poprawiła średnią liczbę FPS i zmierzone opóźnienie komputera. Potrzeba więcej testów, zanim będzie można sformułować szersze twierdzenie.

Na mniejszych ekranach ustaw fokus na ilustracji i przewijaj ją poziomo strzałkami lub gestem.

Czego Hone nie twierdzi

Hone nie twierdzi, że każda optymalizacja poprawia działanie każdego komputera.

Jeden benchmark nie może udowodnić, że zmiana działa w różnych grach, na różnym sprzęcie, ze sterownikami i wersjami systemu Windows. Nie modyfikujemy też pamięci gry, plików systemów ochrony przed oszustwami ani innych wrażliwych plików gry, aby uzyskać wzrost wydajności. Wydajność nie powinna zależeć od ogólnych stwierdzeń, które jedynie brzmią technicznie.

Naszym celem nie jest stworzenie najdłuższej listy zmian. Wybieramy te, które potrafimy wyjaśnić, przetestować, skierować do właściwych systemów i cofnąć.

To standard, który powinna spełniać każda optymalizacja Hone.