Cambiar la prioridad de un proceso solo determina la frecuencia con la que este proceso se ejecutará cuando otros procesos compitan por el tiempo de CPU. No tiene impacto cuando el proceso es el único que usa tiempo de CPU. Un proceso de prioridad mínima en un sistema inactivo obtiene el 100 % del tiempo de CPU, igual que un proceso de prioridad máxima.
Por lo tanto, puede ejecutar su juego con una prioridad más alta, pero eso no hará que se ejecute más rápido a menos que otra cosa en el sistema esté usando una cantidad significativa de tiempo de CPU.
Recomiendo mantener la prioridad más baja que el servidor X, porque si el servidor X quiere tiempo de CPU, es probable que se deba a que el juego le pide que muestre algo complejo, y la visualización suele ser una tarea que exige CPU (pero depende de cuánto del trabajo se realiza en la GPU:las prioridades de la CPU no tienen influencia en la GPU).
Las CPU están diseñadas para ejecutar código. Cambiar las prioridades del proceso no afectará la cantidad de trabajo que realiza la CPU, pero incluso si lo hiciera, eso no dañaría la CPU, solo haría que se calentara más y, por lo tanto, haría que los ventiladores de la computadora funcionaran con más fuerza.
¿Estás hablando de alterar la cantidad de demanda de CPU mientras se ejecuta el subproceso?
Las CPU modernas en realidad usan pasos de velocidad extremadamente rápidos. Por ejemplo, si realizó un análisis del reloj de un Intel Core i5/i7, puede ver que la velocidad del reloj aumenta y disminuye muy rápidamente. Es parte de la forma en que Intel puede ajustar el rendimiento en relación con la cantidad de energía consumida. Es posible que tenga mucha energía disponible en una PC de escritorio, pero el material se convierte en calor cuando la CPU está trabajando más, por lo que es importante obtener el máximo rendimiento por vatio.
Solo lo sé por lo que he leído en otros foros de juegos. No soy un científico de la CPU.
No creo que hagas ningún daño ajustando un hilo a su máxima "desagradable". Lo único que debe vigilar es qué tan caliente se está poniendo su CPU, pero a menos que haya usado sobrevoltaje en el BIOS, entonces es bastante imposible cocinar la CPU antes de que se apague.
Las CPU modernas están diseñadas para cambiar rápidamente de velocidad. Realice una búsqueda de Intel Speed Stepping y 'CPU C state' y verá a qué me refiero.
Usando renice en un programa de Linux no quemará su CPU, pero no necesariamente hará lo que usted quiere que haga.
Las prioridades no tienen nada que ver con la rapidez con la que una CPU ejecuta el código. Ejecuta código de programas en diferentes niveles de prioridad con la misma rapidez. Lo que sí cambian las prioridades es qué programa elige ejecutar el sistema operativo cuando se le da la opción. Las CPU solo pueden ejecutar un "hilo" de ejecución a la vez (técnicamente 1 por núcleo para CPU de varios núcleos). Si necesita hacer más que eso, se basa en la multitarea:alterna entre ejecutar diferentes programas para dar la ilusión de ejecutar más subprocesos que CPU. A la hora de elegir cuánto tiempo dedicar a cada una de estas tareas, lo hace utilizando la prioridad como pista.
Lo que "tiempo real" significa para una computadora es menos "ejecutar tan rápido" y más "no adelantarse a este proceso". La programación en tiempo real es muy importante en muchos campos. Por ejemplo, si estuviera escribiendo un software que gestiona los frenos antibloqueo de un coche, realmente No quiero que mi tarea se retrase unos milisegundos porque el sistema operativo decidió que necesitaba ejecutar un diagnóstico en los limpiaparabrisas. En consecuencia, el software de gestión de frenos antibloqueo en los automóviles se ejecuta con una prioridad de "tiempo real".
A decir verdad, en Linux, el nivel de prioridad de "tiempo real" es un poco inapropiado. Esto se debe a cómo Linux programa sus procesos. En Windows, si tiene un proceso que se ejecuta con una prioridad más alta, los procesos que se ejecutan con prioridades más bajas no reciben tiempo de CPU a menos que la tarea de mayor prioridad esté esperando algo, nada en absoluto. Solo los procesos del kernel pueden ejecutarse sobre una tarea de Windows "en tiempo real". Windows tiene una tonelada de bloatware ejecutándose en segundo plano en todo momento, por lo que aumentar la prioridad a "tiempo real" evita que se ejecute toda esa basura.
Sin embargo, hay un problema con esto. A veces, su tarea de mayor prioridad depende de una de esas tareas de menor prioridad. Esto se llama "inversión de prioridad" y es un gran tema en el mundo de la programación multiproceso. Cuando esto sucede, la tarea de mayor prioridad puede privar a la tarea de menor prioridad, ¡sin darse cuenta de que se está deteniendo a sí misma! En Linux, esto no sucede porque en Linux, las prioridades se ven como una forma de determinar qué parte de la CPU se asigna a cada programa, en lugar de un enfoque de todo o nada. Un proceso que se ejecuta a -20 obtiene sustancialmente más tiempo de CPU que uno que se ejecuta en 0, pero incluso en presencia de un programa -20, el programa 0 obtiene algo tiempo de CPU. Si la memoria sirve, el planificador actual de Linux le da a un programa en -1 el doble de potencia de CPU que en 0, y un programa en -2 el doble que en -1, y así sucesivamente. Esto significa que el 0,9999046 % de su tiempo de CPU irá al programa que está en -20, pero una pequeña fracción lo hace vaya al programa en 0. ¡El programa en 0 se sentirá como si se estuviera ejecutando en un procesador de 200 kHz!
Si alguna vez quieres verdadero en tiempo real, donde puede evitar que cualquier otra cosa se le adelante, debe escribir un controlador de kernel o debe usar una extensión en tiempo real para Linux. Redhat tiene uno llamado MRG, que permite un verdadero procesamiento en tiempo real con Linux. En ese caso, "tiempo real" significa algo específico. Bajo MRG, los usuarios en el grupo "tiempo real" pueden usar estas extensiones de tiempo real (lo que podría mantener el procesador ocupado para siempre, porque intencionalmente no están usando el programador amigable de Linux).