La modification de la priorité d'un processus détermine uniquement la fréquence d'exécution de ce processus lorsque d'autres processus sont en concurrence pour le temps CPU. Il n'a pas d'impact lorsque le processus est le seul à utiliser du temps CPU. Un processus de priorité minimale sur un système autrement inactif obtient 100 % de temps CPU, comme un processus de priorité maximale.
Vous pouvez donc exécuter votre jeu avec une priorité plus élevée, mais cela ne le rendra pas plus rapide à moins que quelque chose d'autre sur le système n'utilise une quantité importante de temps CPU.
Je recommande de garder la priorité inférieure au serveur X, car si le serveur X veut du temps CPU, c'est probablement parce que le jeu lui demande d'afficher quelque chose de complexe, et l'affichage est généralement une tâche exigeante en CPU (mais cela dépend de combien du travail est effectué dans le GPU — les priorités du CPU n'ont aucune influence sur le GPU).
Les processeurs sont conçus pour exécuter du code. Changer les priorités des processus n'affectera pas la quantité de travail effectuée par le processeur, mais même si c'était le cas, cela n'endommagerait pas le processeur, cela ne ferait que le rendre plus chaud et donc faire souffler plus fort les ventilateurs de l'ordinateur.
Parlez-vous de modifier la quantité de demande CPU pendant l'exécution du thread ?
Les processeurs modernes utilisent en fait un pas de vitesse extrêmement rapide. Par exemple, si vous avez analysé la synchronisation d'un processeur Intel Core i5/i7, vous pouvez voir les vitesses d'horloge monter et descendre très très rapidement. Cela fait partie de la façon dont Intel peut ajuster les performances en fonction de la quantité d'énergie consommée. Vous pouvez disposer d'une grande quantité d'énergie sur un ordinateur de bureau, mais l'énergie est convertie en chaleur lorsque le processeur travaille plus fort, il est donc important d'obtenir le meilleur rendement par watt.
Je ne le sais que par ce que j'ai lu sur d'autres forums de jeux. Je ne suis pas un scientifique du CPU.
Je ne pense pas que vous feriez des dégâts en réglant un fil sur sa "méchanceté" maximale. La seule chose que vous devez surveiller est la température de votre CPU, mais à moins que vous n'ayez utilisé la surtension dans le BIOS, il est pratiquement impossible de faire cuire le CPU avant qu'il ne s'éteigne.
Les processeurs modernes sont conçus pour changer rapidement de vitesse. Effectuez une recherche sur Intel Speed Stepping et "CPU C states" et vous verrez ce que je veux dire.
Utilisation de renice sur un programme Linux ne brûlera pas votre processeur, mais il ne fera pas nécessairement ce que vous voulez qu'il fasse.
Les priorités n'ont rien à voir avec la vitesse à laquelle un processeur exécute le code. Il exécute le code des programmes dans différents niveaux de priorité tout aussi rapidement. Ce que les priorités changent, c'est le programme que le système d'exploitation choisit d'exécuter lorsqu'il a le choix. Les processeurs ne peuvent exécuter qu'un seul "thread" d'exécution à la fois (techniquement 1 par cœur pour les processeurs multicœurs). S'il doit faire plus que cela, il s'appuie sur le multitâche - il bascule entre l'exécution de différents programmes pour donner l'illusion d'exécuter plus de threads qu'il n'y a de processeurs. Lors du choix du temps à accorder à chacune de ces tâches, il le fait en utilisant la priorité comme indice.
Ce que "temps réel" signifie pour un ordinateur, c'est moins "courir aussi vite" et plus "ne pas anticiper ce processus". La programmation en temps réel est très importante dans de nombreux domaines. Par exemple, si j'écrivais un logiciel qui gère les freins antiblocage dans une voiture, je vraiment Je ne veux pas que ma tâche s'exécute avec quelques millisecondes de retard car le système d'exploitation a décidé qu'il devait exécuter un diagnostic sur les essuie-glaces. En conséquence, le logiciel de gestion des freins antiblocage des voitures est exécuté en priorité "en temps réel".
À vrai dire, sous Linux, le niveau de priorité "temps réel" est un peu impropre. Cela est dû à la façon dont Linux planifie ses processus. Dans Windows, si vous avez un processus qui s'exécute avec une priorité plus élevée, les processus s'exécutant avec des priorités inférieures ne reçoivent aucun temps CPU à moins que la tâche prioritaire n'attende quelque chose - rien du tout. Seuls les processus du noyau sont autorisés à s'exécuter par-dessus une tâche Windows "en temps réel". Windows a une tonne de bloatware s'exécutant en arrière-plan à tout moment, donc l'augmentation de la priorité sur "temps réel" empêche l'exécution de tous ces fichiers indésirables.
Cependant, il y a un problème avec cela. Parfois, votre tâche prioritaire dépend de l'une de ces tâches prioritaires inférieures. C'est ce qu'on appelle "l'inversion de priorité" et c'est un sujet important dans le monde de la programmation multithread. Lorsque cela se produit, la tâche de priorité supérieure peut affamer la tâche de priorité inférieure, sans se rendre compte qu'elle s'arrête d'elle-même ! Sous Linux, cela ne se produit pas car sous Linux, les priorités sont considérées comme un moyen de déterminer quelle partie du processeur est attribuée à chaque programme, plutôt qu'une approche tout ou rien. Un processus exécuté à -20 obtient substantiellement plus de temps CPU qu'un programme fonctionnant à 0, mais même en présence d'un programme -20, le programme 0 en obtient certains Temps CPU. Si la mémoire est bonne, le planificateur Linux actuel donne à un programme à -1 deux fois plus de puissance CPU qu'un 0, et à un programme à -2 deux fois plus qu'à -1, et ainsi de suite. Cela signifie que 0,9999046 % de votre temps CPU ira au programme qui est à -20, mais une petite fraction le fait allez au programme à 0. Le programme à 0 aura l'impression de tourner sur un processeur à 200 kHz !
Si jamais vous voulez vrai en temps réel, où vous pouvez empêcher quoi que ce soit d'autre de vous devancer, vous devez écrire un pilote de noyau ou vous devez utiliser une extension en temps réel pour Linux. Redhat en a un appelé MRG, qui permet un véritable traitement en temps réel avec Linux. Dans ce cas, "temps réel" signifie quelque chose de spécifique. Sous MRG, les utilisateurs du groupe "temps réel" sont autorisés à utiliser ces extensions en temps réel (ce qui pourrait occuper le processeur pour toujours, car ils n'utilisent pas intentionnellement le sympathique ordonnanceur Linux).