¿Por qué la priorización de procesos no produce una mejora de la velocidad?

Tengo 2 aplicaciones que utilizan muchos recursos del sistema. Cuando disminuyo la prioridad de uno en el Administrador de tareas, mientras que aumento el otro, no noto ninguna mejora significativa en la velocidad de la aplicación con la prioridad más alta.

¿Por qué es esto? ¿Hay más cosas o hay más por hacer?

La prioridad no ayuda cuando el cuello de botella es la propia CPU. Lo que realmente prioriza es afectar el algoritmo de programación que utiliza el sistema operativo para determinar qué proceso se ejecuta a continuación, ya que no hay suficientes procesadores en la mayoría de los sistemas para ejecutar cada proceso de manera continua.

Una tarea de mayor prioridad llegará a la parte superior de la cola más rápido, por lo que esto ayuda con la latencia general, pero si su proceso está agotando todo el intervalo de tiempo, se asigna en el cálculo real, entonces la programación no va a cambiar nada allí. Cambiar la prioridad es más útil cuando tiene un proceso que está esperando E / S y desea que responda mejor.

La prioridad es el tiempo de CPU. ¿Todos los núcleos se utilizan al 100% todo el tiempo? De lo contrario, la prioridad no tendría ningún efecto. Muy a menudo, la CPU no es el cuello de botella, y son recursos de memoria, disco o GPU.

La prioridad solo importa cuando hay más subprocesos ejecutables que los núcleos de CPU disponibles. Cuando eso sucede, la prioridad controla qué hilos se ejecutan. En la mayoría de los sistemas, no hay suficiente cómputo para ninguna disputa en la CPU: todos los hilos están bloqueados , esperando que algo suceda. Eso podría estar esperando que escriba algo, mueva el mouse, toque la pantalla o que lleguen datos del disco, la red, algún otro dispositivo que haya conectado o que otro hilo termine de trabajar en datos críticos estructura. Podría estar esperando que parte del programa sea leída desde el disco o alguna memoria que fue intercambiada para ser leída, en lugar de leer explícitamente un archivo.

En Windows, el planificador mantiene una cola de subprocesos ejecutables en cada nivel de prioridad. Cuando toma una decisión de programación, ya sea que un subproceso ha agotado su cantidad (tiempo permitido antes de que algo más necesite ejecutarse), lo que significa que otro subproceso debería tener un turno, o el subproceso se ha bloqueado y ya no es ejecutable, o una prioridad más alta el subproceso se ha desbloqueado: se programará el siguiente subproceso de la cola en el nivel de máxima prioridad con cualquier subproceso ejecutable. Si el hilo que se estaba ejecutando ha agotado su cantidad, se coloca al final de la cola. Si es el único subproceso en su nivel de prioridad que se puede ejecutar, y no hay otros subprocesos ejecutables de mayor prioridad, pero que no se ejecutan, tendrá otro turno.

En sistemas multinúcleo / multiprocesador, puede haber restricciones sobre qué núcleos puede ejecutar un subproceso. Además, el sistema intenta mantener los subprocesos en su núcleo ideal y dentro de su nodo NUMA para que los datos del subproceso todavía estén probablemente en la memoria caché de ese núcleo y tenga acceso rápido a los datos que creó. Los subprocesos aún se ejecutarán en núcleos no ideales si no hay elección de qué ejecutar a continuación.

El sistema utiliza varios aumentos de prioridad dinámica y tamaños cuánticos dinámicos para que la aplicación en primer plano tenga más tiempo (si lo necesita) que los procesos en segundo plano, y para que los procesos puedan reaccionar rápidamente cuando se completen las operaciones de E / S (incluyendo mouse, teclado y entrada de pantalla táctil). Además, el aumento de prioridad se utiliza para evitar las inversiones prioritarias, donde un subproceso de alta prioridad está esperando un recurso que actualmente tiene un subproceso de baja prioridad. Si también se está ejecutando un subproceso de prioridad media, privará al subproceso de baja prioridad del tiempo de procesador, reteniendo el subproceso de alta prioridad. Por lo tanto, el subproceso de baja prioridad se aumenta temporalmente a la prioridad más alta, por lo que obtiene tiempo y, con suerte, libera el recurso que necesita el subproceso de alta prioridad.

Antes de Windows Vista, la prioridad del hilo no tenía efecto sobre la rapidez con que se completaban las operaciones de E / S. Desde Windows Vista, las E / S también pueden tener una prioridad, que de forma predeterminada proviene de la prioridad del subproceso.

Resumen: en gran medida no verá ningún efecto al cambiar las prioridades de los subprocesos a menos que su CPU esté muy cargada, e incluso entonces el efecto generalmente será mínimo. Si el proceso tiene que esperar E / S o no está compitiendo con otros procesos por el tiempo de CPU, ya se está ejecutando lo más rápido que puede y cambiar la prioridad no lo hará más rápido.

En general, se necesita un esfuerzo adicional para hacer que un programa use más de una CPU (agregando subprocesos múltiples). Entonces, incluso si el programa tiene la prioridad más alta disponible, es posible que solo esté usando un núcleo.

Otros posibles problemas:

• El programa podría ser ineficiente / mal escrito
• Podría ralentizarse debido al acceso "lento" al disco o una red lenta

Incluso aumentar la prioridad de E / S de un proceso vinculado a E / S no necesariamente hará que se ejecute más rápido. Por ejemplo, si es un consumidor de datos producidos por un proceso separado, posiblemente remoto, y se mantiene al día con la velocidad a la que esa fuente produce los datos, entonces no puede ir más rápido o tener un mayor rendimiento.

Al contrario de lo que se establece categóricamente en la primera oración de la respuesta actualmente aceptada ( /superuser//a/752587/322588 ), los cambios de prioridad son más efectivos cuando la CPU es el cuello de botella, como se explica en la respuesta de Mike Dimmick ( /superuser//a/752864/322588 ). Además, la declaración en el segundo párrafo de la respuesta aceptada, "si su proceso está agotando el intervalo de tiempo completo que se asigna en el cálculo real, entonces la programación no va a cambiar nada allí" es completamente incorrecto a menos que el proceso ya tenga la mayor prioridad de todos subprocesos ejecutables siempre que esté esperando ejecutarse. Esto se debe a que, en todas las demás circunstancias, es probable que aumentar la prioridad le otorgue más tiempos por intervalo de reloj de pared.

Mike Dimmick señaló los problemas con esta respuesta hace un par de días, y proporcionó una respuesta mucho mejor, sin embargo, el primero sigue ganando votos inexplicablemente. La afirmación de su autor de que simplemente está tontando su respuesta para nosotros, tontos, no es plausible, porque no es simplemente simple, o incluso simplista, es totalmente errónea, al menos con respecto a los procesos vinculados a la CPU.

Descargo de responsabilidad: no conozco al Sr. Dimmick, aunque puedo decir que sabe de qué está escribiendo.