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


18

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?


66
Es como la vida real. Si tiene una mayor prioridad para subir a un avión que otro pasajero, ¡eso no significa que el vuelo le tomará menos tiempo!
Mehrdad

Respuestas:


28

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.


55
La prioridad ayuda cuando el cuello de botella es demasiados hilos que son ejecutables. Los subprocesos de mayor prioridad en Windows que permanecen ejecutables al final de su intervalo de tiempo tendrán otra oportunidad de ejecutarse con preferencia a un subproceso de menor prioridad (Windows intenta no privar a los subprocesos de baja prioridad y en ocasiones los aumenta). La prioridad tiene poco efecto en los subprocesos que esperan E / S: Windows aumenta temporalmente la prioridad de un subproceso después de que se completa una E / S, dependiendo del tipo de E / S que estaba esperando.
Mike Dimmick

4

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.


3

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.


0

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

0

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.


Quizás entendiste mal; La pregunta era sobre los procesos que se ejecutan más rápido. Los procesos vinculados a la CPU agotarán toda su unidad de programación (cuántica) y luego pasarán a una cola de procesos listos al final. En un sistema operativo de escritorio como Windows, eso significa que el proceso tiene posibilidades de 1 / Hz cuántico para ejecutarse cada segundo. Cambiar la prioridad (generalmente) no cambia la duración de sus segmentos de tiempo. Siempre tomará la misma cantidad de cuantos de programación para completar. Crucialmente , así es como Windows realmente mide el tiempo de ejecución del proceso: número de cuantos programados.
Andon M. Coleman

El proceso puede finalizar antes, pero aún se ejecutó para la misma cantidad de unidades de programación. Cuando un proceso vinculado a E / S se coloca en la lista de espera, puede tener una segunda oportunidad de ejecutarse y evitar un proceso en ejecución con una prioridad más baja antes de que su cuantum expire si se completa su operación de E / S. Los procesos vinculados a la CPU no tienen esta libertad, agotan su intervalo de tiempo completo y luego entran en una cola lista. Que es posible para ellos para funcionar inmediatamente después si tienen una prioridad suficientemente alta, pero eso no tiene nada que ver con la forma en que Windows mide el tiempo de ejecución.
Andon M. Coleman

La prioridad en un proceso enlazado de E / S en espera es fundamentalmente diferente y puede tener un impacto medible en el tiempo de ejecución informado en Windows. Nuevamente, Windows mide el tiempo de ejecución como la cantidad de cuantos que expiraron (incluso si un proceso gasta 1 ms de una cantidad cuántica de 10 ms en ejecución y luego espera voluntariamente los 9 ms restantes para E / S, el núcleo de Windows cuenta que vale 10 ms del tiempo de ejecución en modo de usuario). Preemption puede ayudar a las aplicaciones vinculadas de E / S a tomar menos cuantos para finalizar. Otros núcleos (p. Ej., Linux) pueden medir correctamente los cuantos parciales en el tiempo de ejecución de un proceso, pero Windows no.
Andon M. Coleman

@ AndonM.Coleman A partir de Vista y posterior, sí, puede y lo hace.
Jamie Hanrahan

@JamieHanrahan: Bueno, siempre puedes llamar timeBeginPeriod (...), lo que ya hace cualquier cosa interactiva. Un juego generalmente establecerá esto en 1 cuando comience, y eso aplica un intervalo de programación de 1 ms en todos los ámbitos a todo lo que se ejecuta en el sistema. No está aislado solo del proceso que lo hizo. Es parte de la razón por la que es difícil tomar Windows en serio para la multitarea.
Andon M. Coleman
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.