Come Hone valuta le ottimizzazioni delle prestazioni

Molte modifiche per PC cercano di sembrare convincenti. Cambia una chiave del Registro di sistema, disattiva una funzione di Windows, regola un’impostazione e poi, all’improvviso, chiamalo aumento degli FPS.

Per Hone non basta.

Prima di aggiungere un’ottimizzazione, dobbiamo capire cosa cambia, perché potrebbe essere utile e come possiamo testarla. Se non riusciamo a rispondere a queste domande, non la pubblichiamo.

In breve

Ogni ottimizzazione Hone richiede:

• Un problema reale da risolvere
• Una spiegazione chiara di ciò che cambia
• Un obiettivo misurabile
• Rischi noti
• Un modo sicuro per annullarla
• Prove abbastanza solide da giustificare la modifica
• Una definizione chiara dei sistemi che possono beneficiarne

Una modifica non deve necessariamente aiutare ogni PC, ma deve avere senso e non creare un problema più grande di quello che risolve.

Sugli schermi più piccoli, porta il focus sulla figura e usa i tasti freccia o scorri per spostarti in orizzontale.

1. Partire dal problema

Iniziamo dai problemi comuni che un giocatore può notare, ad esempio:

• Scatti causati dall’attività in background
• Frame time instabili
• Latenza di input elevata
• Attività del disco che causa blocchi momentanei
• Latenza di rete sotto carico
• App che competono con il gioco per CPU o memoria

Se non riusciamo a descrivere il problema, la modifica viene rifiutata automaticamente.

«Questa impostazione esiste» non è un motivo per cambiarla. «Questa impostazione controlla un comportamento che potrebbe causare latenza durante il gioco» è qualcosa che possiamo esaminare.

2. Capire cosa cambia la modifica

Ogni ottimizzazione richiede una spiegazione diretta.

Dobbiamo essere in grado di rispondere:

• Quale parte di Windows interessa?
• Quale comportamento cambia dopo l’applicazione?
• Perché potrebbe influire sul gioco?
• Quali sistemi hanno maggiori probabilità di beneficiarne?

Prendiamo come esempio la nostra modifica dell’affinità dei dispositivi, che cambia il modo in cui determinate attività hardware vengono assegnate ai core della CPU. Su alcuni sistemi, spostare tali attività può ridurre la contesa e la latenza.

Questo non dimostra che la modifica sia sempre utile, ma ci offre un meccanismo da testare.

Se non riusciamo a spiegare il meccanismo, consideriamo la modifica una supposizione.

3. Individuare il rischio

Cerchiamo ciò che potrebbe andare storto prima di cercare un aumento delle prestazioni.

A seconda del cambiamento, un’ottimizzazione potrebbe influire su:

• Stabilità
• Regolarità dei frame
• Latenza di input
• Driver e dispositivi collegati
• Avvio dei giochi
• Compatibilità con i sistemi anti-cheat
• Consumo energetico e temperature
• Aggiornamenti di Windows

Alcune modifiche sono più facili da controllare di altre. Ridurre l’attività in background durante una sessione di gioco è più facile da annullare rispetto a cambiare il comportamento di basso livello di un dispositivo.

Una modifica più rischiosa non viene rifiutata automaticamente. Richiede però prove più solide, un’applicazione più mirata e un ripristino affidabile.

Se non possiamo annullare una modifica in sicurezza, non la trattiamo con leggerezza.

4. Definire cosa significa successo

Non tutte le ottimizzazioni sono pensate per aumentare gli FPS medi.

Una modifica può invece ridurre gli scatti, migliorare la regolarità dei frame, abbassare la latenza di input, ridurre l’attività in background o stabilizzare le prestazioni della rete.

Scegliamo il test in base all’affermazione:

• FPS e fluidità: FPS medi, valori minimi dell’1% e dello 0.1%, frame time e scatti
• Latenza: latenza misurata del PC, tempistiche dei driver, comportamento degli interrupt o pianificazione della CPU
• Archiviazione: latenza di lettura e scrittura, tempo di risposta e blocchi durante il caricamento delle risorse
• Rete: ping, jitter, comportamento dei pacchetti e bufferbloat

Questo è importante perché una misurazione sbagliata può far sembrare valido un risultato debole.

Una modifica alla rete non dovrebbe essere valutata in base agli FPS. Un miglioramento della latenza non dovrebbe essere ignorato perché gli FPS medi sono rimasti invariati. FPS medi più alti non sono un vantaggio se gli scatti peggiorano.

Sugli schermi più piccoli, porta il focus sulla figura e usa i tasti freccia o scorri per spostarti in orizzontale.

5. Eseguire test controllati

Le prestazioni di un PC sono variabili.

I risultati possono cambiare a causa della compilazione degli shader, delle attività di Windows, delle temperature, delle app in background, di mappe diverse, delle condizioni del server o persino della direzione in cui guarda il giocatore durante un test.

Controlliamo quanti più fattori possibile:

• Stesso PC e stesso hardware
• Stesso gioco, mappa, scena, percorso o replay
• Stesse impostazioni grafiche
• Stesse versioni di Windows e dei driver
• Stesso piano di alimentazione
• Stesse app in background
• Stesso metodo di acquisizione e stessa durata del test
• Stesso limite di FPS e stesse impostazioni di sincronizzazione
• Stesse condizioni di riavvio

Testiamo inoltre una sola modifica alla volta. Se cinque modifiche vengono abilitate insieme, non possiamo sapere quale sia stata utile o quale abbia causato un problema.

Una singola esecuzione positiva non basta.

Per ogni PC, eseguiamo il test di riferimento da 3 a 5 volte prima di applicare la modifica. Poi applichiamo la modifica una sola volta, riavviamo se necessario ed eseguiamo lo stesso test da 3 a 5 volte dopo.

Ogni confronto prima e dopo comprende quindi da 6 a 10 esecuzioni totali per PC. Ripetere il test ci aiuta a tenere conto della normale variabilità e a individuare i risultati influenzati dalla compilazione degli shader, dalla cache o da altre condizioni temporanee.

Prima di confrontare i risultati, osserviamo quanto variano tra loro le esecuzioni di riferimento. Una modifica viene considerata un miglioramento solo quando i risultati successivi superano tale variazione normale e il cambiamento compare con costanza in più esecuzioni.

Se i risultati precedenti e successivi sono troppo simili, la conclusione è «nessuna differenza misurabile».

Ogni modifica segue lo stesso processo prima che traiamo una conclusione. Se il risultato non supera test ripetuti, non lo definiamo un miglioramento. È qui che Hone si distingue dalla maggior parte degli strumenti di ottimizzazione.

Sugli schermi più piccoli, porta il focus sulla figura e usa i tasti freccia o scorri per spostarti in orizzontale.

6. Confrontare il risultato con il rischio

Un miglioramento misurabile non merita sempre di essere pubblicato.

Un guadagno piccolo e ripetibile derivante da una modifica a basso rischio può essere utile. Lo stesso guadagno potrebbe non giustificare una modifica capace di causare arresti anomali, scatti o problemi ai dispositivi.

Esaminiamo il risultato completo:

• Quanto è stato grande il miglioramento?
• Si è ripetuto?
• La regolarità dei frame time è migliorata?
• La latenza è migliorata?
• Un’altra metrica è peggiorata?
• Il sistema è rimasto stabile?
• La modifica può essere annullata?
• Aiuta solo determinati componenti hardware o giochi?

La domanda non è soltanto se un numero è aumentato. Il beneficio deve giustificare la modifica.

7. Definire dove aiuta e dove no

La maggior parte delle ottimizzazioni dipende da determinate condizioni.

Una modifica può essere utile quando:

• Il gioco è limitato dalla CPU
• Le app in background competono con il gioco
• Il sistema presenta picchi di latenza dei driver
• L’attività di archiviazione causa blocchi momentanei
• La CPU è più vecchia o dispone di meno risorse
• La latenza di rete aumenta mentre la connessione è occupata

Questo non rende debole la modifica.

Preferiamo fare un’affermazione specifica che possiamo sostenere anziché promettere a tutti un aumento degli FPS.

8. Mantenere, cambiare o rifiutare

Ogni ottimizzazione porta a una delle tre decisioni.

Mantenere

La manteniamo quando:

• Il meccanismo è chiaro
• La metrica prevista migliora
• Il risultato si ripete
• Il rischio è giustificato
• La modifica è reversibile
• Sappiamo dove dovrebbe essere usata

«Rischio accettabile» non significa assenza di rischio. Significa che il possibile svantaggio è limitato, compreso e recuperabile.

Cambiare

A volte l’idea è valida, ma l’implementazione non è pronta.

La modifica può migliorare una metrica e peggiorarne un’altra. Potrebbe dover essere destinata a componenti hardware o giochi specifici. Potrebbe anche richiedere impostazioni migliori o un ripristino più sicuro.

Un benchmark positivo non significa automaticamente che pubblicheremo la modifica.

Rifiutare

Rifiutiamo una modifica quando:

• Non riusciamo a spiegare cosa cambia
• Il risultato non si ripete
• Il beneficio è troppo piccolo per avere importanza
• Causa instabilità o scatti
• Il rischio di compatibilità è troppo elevato
• Non può essere annullata in sicurezza
• Le prove non sostengono l’affermazione

Rifiutare una modifica fa sempre parte del processo; pubblicarne una non dimostrata rappresenta il fallimento.

Per esempio: affinità dei dispositivi

Abbiamo testato questa ottimizzazione seguendo il metodo descritto nell’articolo. Stessa configurazione, stessi scenari e stesse impostazioni, con cinque acquisizioni prima di applicare la modifica e cinque dopo. I risultati hanno mostrato un piccolo aumento delle prestazioni medie, da circa 177 FPS a 182 FPS. Anche il frame time medio e la latenza misurata del PC sono leggermente migliorati.

Invece di affermare troppo presto che «questa modifica aumenta gli FPS», siamo giunti alla seguente conclusione:

Su questo sistema, la modifica ha migliorato gli FPS medi e la latenza misurata del PC. Servono altri test prima di formulare un’affermazione più ampia.

Sugli schermi più piccoli, porta il focus sulla figura e usa i tasti freccia o scorri per spostarti in orizzontale.

Cosa non afferma Hone

Hone non afferma che ogni ottimizzazione migliori ogni PC.

Un singolo benchmark non può dimostrare che una modifica funzioni con giochi, hardware, driver e versioni di Windows diversi. Inoltre, non modifichiamo la memoria dei giochi, i file dei sistemi anti-cheat o altri file di gioco sensibili per ottenere miglioramenti delle prestazioni. Le prestazioni non dovrebbero dipendere da affermazioni generiche che sembrano tecniche.

Il nostro obiettivo non è creare l’elenco di modifiche più lungo. Selezioniamo invece i cambiamenti che possiamo spiegare, testare, indirizzare e annullare.

Questo è lo standard che vogliamo venga soddisfatto da ogni ottimizzazione Hone.