La modifica della priorità di un processo determina solo la frequenza con cui questo processo verrà eseguito quando altri processi competono per il tempo della CPU. Non ha alcun impatto quando il processo è l'unico che utilizza il tempo della CPU. Un processo con priorità minima su un sistema altrimenti inattivo ottiene il 100% del tempo della CPU, come un processo con priorità massima.
Quindi puoi eseguire il tuo gioco con una priorità più alta, ma ciò non lo renderà più veloce a meno che qualcos'altro sul sistema non utilizzi una quantità significativa di tempo della CPU.
Raccomando di mantenere la priorità più bassa rispetto al server X, perché se il server X vuole il tempo della CPU, è probabile che sia perché il gioco gli sta chiedendo di visualizzare qualcosa di complesso, e la visualizzazione è solitamente un'attività impegnativa per la CPU (ma dipende da quanto del lavoro viene svolto nella GPU — le priorità della CPU non hanno alcuna influenza sulla GPU).
Le CPU sono progettate per eseguire codice. La modifica delle priorità del processo non influirà sulla quantità di lavoro svolto dalla CPU, ma anche se lo facesse, ciò non danneggerebbe la CPU, la farebbe solo surriscaldare e quindi le ventole del computer soffierebbero più forte.
Stai parlando di alterare la quantità di richiesta della CPU mentre è in esecuzione il thread?
Le CPU moderne utilizzano in realtà un aumento della velocità estremamente rapido. Ad esempio, se hai analizzato il clock di un Intel Core i5/i7, puoi vedere le velocità di clock che sfarfallano su e giù molto velocemente. Fa parte del modo in cui Intel può ottimizzare le prestazioni rispetto alla quantità di energia assorbita. Potresti avere un sacco di energia disponibile in un PC desktop, ma il materiale viene convertito in calore quando la CPU lavora di più, quindi è importante ottenere il massimo per watt.
Lo so solo da quello che ho letto su altri forum di gioco. Non sono uno scienziato della CPU.
Non penso che faresti alcun danno dall'accordatura di un thread alla sua massima "cattiveria". L'unica cosa che dovresti tenere d'occhio è quanto si surriscalda la tua CPU, ma a meno che tu non abbia utilizzato l'overvolting nel BIOS, è praticamente impossibile cuocere la CPU prima che si spenga.
Le moderne CPU sono progettate per cambiare rapidamente velocità. Fai una ricerca per Intel Speed Stepping e "CPU C states" e capirai cosa intendo.
Utilizzando renice
su un programma Linux non brucerà la tua CPU, ma non farà necessariamente quello che vuoi che faccia.
Le priorità non hanno niente ha a che fare con la velocità con cui una CPU esegue il codice. Esegue il codice da programmi in diversi livelli di priorità ugualmente velocemente. Le priorità cambiano è quale programma il sistema operativo sceglie di eseguire quando viene data una scelta. Le CPU possono eseguire solo un "thread" di esecuzione alla volta (tecnicamente 1 per core per CPU multi-core). Se ha bisogno di fare di più, si affida al multitasking:passa avanti e indietro tra l'esecuzione di diversi programmi per dare l'illusione di eseguire più thread di quante siano le CPU. Quando si sceglie quanto tempo dedicare a ciascuna di queste attività, lo fa utilizzando la priorità come suggerimento.
Ciò che significa "tempo reale" per un computer è meno "esegui così velocemente" e più "non anticipare questo processo". La programmazione in tempo reale è molto importante in molti campi. Ad esempio, se stavo scrivendo un software che gestisce i freni antibloccaggio in un'auto, davvero non voglio che il mio compito venga eseguito con qualche millisecondo di ritardo perché il sistema operativo ha deciso che era necessario eseguire una diagnostica sui tergicristalli. Di conseguenza, il software di gestione del freno antibloccaggio nelle auto viene eseguito con priorità "in tempo reale".
Sinceramente, in Linux, il livello di priorità "tempo reale" è un termine un po' improprio. Ciò è dovuto al modo in cui Linux pianifica i suoi processi. In Windows, se si dispone di un processo in esecuzione con una priorità più alta, ai processi in esecuzione con priorità più bassa non viene assegnato alcun tempo di CPU a meno che l'attività con priorità più alta non sia in attesa di qualcosa, nessuna. Solo i processi del kernel possono essere eseguiti al di sopra di un'attività di Windows "in tempo reale". Windows ha tonnellata di bloatware in esecuzione in background in ogni momento, quindi l'aumento della priorità a "tempo reale" impedisce l'esecuzione di tutta quella spazzatura.
Tuttavia, c'è un problema con questo. A volte la tua attività con priorità più alta dipende da una di quelle attività con priorità più bassa. Questo si chiama "inversione di priorità" ed è un argomento importante nel mondo della programmazione multithread. Quando ciò accade, l'attività con priorità più alta può far morire di fame l'attività con priorità più bassa, senza rendersi conto che si sta arrestando da sola! In Linux, questo non accade perché in Linux le priorità sono viste come un modo per determinare quale parte della CPU viene assegnata a ciascun programma, piuttosto che un approccio tutto o niente. Un processo in esecuzione a -20 ottiene sostanzialmente più tempo di CPU rispetto a uno eseguito a 0, ma anche in presenza di un programma -20, il programma 0 ottiene alcuni Tempo CPU. Se la memoria serve, l'attuale scheduler di Linux fornisce a un programma a -1 il doppio della potenza della CPU di uno 0, e un programma a -2 il doppio di un -1, e così via. Ciò significa che lo 0,9999046% del tempo della tua CPU andrà al programma che è a -20, ma una piccola frazione fa vai al programma a 0. Sembrerà che il programma a 0 stia girando su un processore a 200kHz!
Se mai vorrai vero tempo reale, dove puoi impedire a qualsiasi altra cosa di anticiparti, devi scrivere un driver del kernel o devi usare un'estensione in tempo reale per Linux. Redhat ne ha uno chiamato MRG, che consente una vera elaborazione in tempo reale con Linux. In tal caso "tempo reale" significa qualcosa di specifico. Sotto MRG, gli utenti nel gruppo "tempo reale" possono utilizzare queste estensioni in tempo reale (che potrebbero tenere il processore occupato per sempre, perché non stanno intenzionalmente utilizzando il simpatico programmatore Linux).