¿Por qué su código no debe usar el 100% de la CPU? [cerrado]

Si la refrigeración es insuficiente, la CPU podría sobrecalentarse. Pero todas (bueno, al menos todas las CPU de PC modernas) cuentan con varios mecanismos de protección térmica que acelerarán la velocidad del reloj o, como último recurso, se apagarán.

Entonces, sí, en una computadora portátil polvorienta, la carga del 100% de la CPU puede causar problemas temporales, pero nada se romperá o "degradará" (lo que sea que eso signifique).

Para problemas relacionados con la CPU, el 100% de la carga de CPU es el camino correcto.

En cuanto a la capacidad de respuesta de la aplicación (UI), ese es un concepto separado de la utilización de la CPU. Es completamente posible tener una aplicación que no responde que usa 1% de CPU, o una aplicación sensible que usa 100% de CPU. La capacidad de respuesta de la interfaz de usuario se reduce a la cantidad de trabajo realizado en el subproceso de la interfaz de usuario, y la prioridad del subproceso de la interfaz de usuario frente a otras hebras.

Los programas de Windows (winforms / WPF) deben permanecer en todo momento receptivos. Con una implementación ingenua de un proceso que utiliza 100% de recursos de CPU, es muy fácil hacer que su programa o incluso su sistema parezcan lentos e inestables.

Con una buena implementación (por ejemplo: usar un hilo separado con una prioridad más baja) no debería ser un problema.

No debes preocuparte por que tu CPU se rompa antes.

En general, no hay nada de malo en que un programa utilice el 100% de la CPU mientras que en realidad está haciendo un trabajo útil y no le está quitando tiempo a algo más importante . Si una plataforma de hardware en particular es, por ejemplo. solo es capaz de usar el 100% de la CPU de forma continua durante un segundo antes de que tenga que acelerarse de nuevo al 50% para evitar el sobrecalentamiento, generalmente es mejor para una aplicación que tiene un trabajo útil que realizar para ejecutar tan rápido como sea puede, y deje que la CPU o el sistema operativo maneje cualquier limitación necesaria, que para que una aplicación adivine qué tan rápido "debería" ejecutarse. Si una aplicación o subproceso tiene un trabajo de baja prioridad que hacer, lo que sería útil pero no crítico en todo momento, puede ser útil para el sistema operativo limitar el uso de la CPU de tareas de baja prioridad al 50%, de modo que si la CPU tiene que hacerlo algo rápido estará listo para "correr" por un segundo, pero la aplicación no debería preocuparse por esas cosas más allá de solicitar una prioridad de subprocesos baja.

Las situaciones más grandes en las que es malo usar un 100% de CPU son cuando:

• La aplicación está ocupada, esperando algún evento que no se acelerará con un sondeo persistente [y en realidad podría demorarse si el esfuerzo perdido comprueba si la tarea realizada ocupa recursos de la CPU que, de lo contrario, podrían gastarse haciendo la tarea].

• La aplicación está redibujando la pantalla con demasiada frecuencia. La definición de "excesivamente frecuente" dependerá en cierta medida de la naturaleza del dispositivo de visualización y del contenido que se muestra. Si el hardware de la pantalla puede mostrar 120 fps, puede haber casos en los que la animación se pueda mostrar a 120 fps sin agregar desenfoque de movimiento, pero no se pueda mostrar limpiamente a velocidades de cuadro más bajas sin agregarlo. Si renderizar un cuadro con desenfoque de movimiento tomaría mucho más tiempo que renderizarlo sin él, entonces renderizar a 120 fps en el hardware que lo admite no podría ser más costoso que renderizar a una velocidad de cuadro más lenta con movimiento borroso. [Situación simple: una rueda con 29 radios, girando a una revolución por segundo. A 120 fps, la rueda parecería girar con la velocidad y dirección adecuadas; a 60 fps, una rueda parpadeante parecería girar lentamente en la dirección opuesta].

El primero es claramente reconocible como malo. El segundo es un poco más sutil. Si uno está apuntando a una plataforma móvil, puede ser conveniente en algunos casos permitir que los usuarios seleccionen la velocidad de cuadros de la animación deseada, ya que a algunos usuarios no les preocupa la vida útil de la batería pero desean la mejor calidad de animación, mientras que otros aceptan una calidad inferior. Animación a cambio de una mejor duración de la batería. En lugar de hacer que la aplicación intente adivinar dónde debería estar la compensación, puede ser útil permitir que el usuario la personalice.

"Las CPU modernas son baratas y se degradarán rápidamente al 100% de la CPU".

No creo que nadie haya abordado la parte "degradada" de esta pregunta. Los circuitos integrados se degradarán cuando la temperatura del troquel supere los límites del fabricante. Los circuitos integrados suelen estar diseñados para funcionar hasta 125C, aunque cada aumento de 10C acorta la vida en un 50%

Los procesadores no siempre tenían regulación térmica. Luego, algunos AMD Durons experimentaron problemas (supuestamente era posible destruir uno si se ejecutaba sin el disipador térmico). Ahora, todos los procesadores de PC tendrán sensores de temperatura incorporados que realimentarán el reloj de la CPU y reducirán la velocidad del reloj para evitar daños. Por lo tanto, es posible que su programa utilice el 100% de la CPU disponible, pero la CPU solo se ejecuta al 75% de su velocidad nominal porque su enfriamiento es inadecuado.

Dentro de un programa de usuario no es el lugar correcto para tratar de administrar el consumo de CPU. Generalmente, su programa debe alternar entre hacer las cosas lo más rápido posible y esperar, suspendido, para la entrada o el acceso al disco. Debes evitar la espera ocupada y el bloqueo de giro si es posible, pero como una cortesía para el resto del sistema.

Tanto Windows como Linux tienen sistemas "govenor" de CPU que realizarán el rendimiento y la gestión térmica. Debido a que esto se realiza a nivel del sistema operativo, puede explicar el consumo total de CPU del sistema. Es responsabilidad del sistema operativo administrar el hardware y evitar que los programas del usuario lo utilicen indebidamente. Es responsabilidad del propietario del hardware mantener los ventiladores limpios y en funcionamiento, y el fabricante instalar los disipadores de calor y los ventiladores adecuados en primer lugar.

Hay algunos casos en los que los dispositivos tienen una refrigeración inadecuada, pero una avalancha de devoluciones enseña a los fabricantes a no hacer eso.

Para jugar al defensor del diablo: de alguna manera, un programa que no puede alcanzar el 100% de utilización podría causar un desgaste peor: a menos que se suspenda a la espera de una pulsación de tecla, es probable que se suspenda a la espera de la E / S del disco la mayoría de los hora. Y los discos son (aún en general) grandes dispositivos mecánicos que están sujetos a desgaste mecánico o al riesgo de golpes / efectos giroscópicos cuando se mueven, sin mencionar el consumo de energía.

  

".. Las CPU modernas son baratas y se degradarán rápidamente al 100% de la CPU".

No tiene que preocuparse por la "degradación de la CPU" en absoluto. Las CPU modernas no son de menos calidad que en tiempos anteriores.

Es muy costoso (y se está volviendo más caro cada dos años) para hacer CPU, algunos miles de millones para construir una nueva fábrica no son infrecuentes (ver enlace).

enlace

Los costos de producción de una CPU dependen como máximo del no. de unidades producidas. Este es un hecho bien conocido en la economía. Esa es la razón por la que pueden ser vendidos (relativamente) "baratos" después de todo. (Creo que no es necesario ningún enlace aquí)

Puedo enumerar una serie de razones por las que consideraría que las CPU modernas tienden a ser de más calidad que en "tiempos anteriores".

Pero solo lo más importante: Ventajas en las pruebas. La electrónica moderna está "diseñada para prueba". Ya sea software o hardware, la amplia visión de valorar las pruebas en casi todo lo demás, no es tan antigua. Para las CPU, incluso se toman las pruebas para determinar los diferentes tipos de precios y frecuencias, por ejemplo, Las mejores CPUs se venden con las frecuencias más altas. A pesar de eso, los procesadores más baratos a menudo pueden operar con mayor frecuencia que los vendidos; están paralizados solo porque el fabricante quiere vender algunos procesadores de "alto nivel" con precios más altos.

(Por otro lado, por supuesto, hay más errores posibles para un procesador con más de 1.500 millones de transistores como es normal en la actualidad que con algunos miles de transistores de un procesador de los años 70. Pero esto no contradice mi respuesta, OMI. Los procesadores en general tienden a tener muchos errores conocidos, al menos en microcódigo, pero esto no está sujeto aquí.)

Incluso hay más razones para no preocuparse por la degradación de la CPU de su programa:

• La primera razón es que las CPU modernas disminuyen su frecuencia o aceleran, si se están calentando demasiado.

  Debe quedar claro que si utiliza la CPU 100% las 24 horas del día, los 7 días de la semana, todo el año, normalmente morirá antes que una CPU que se usa solo cada segunda semana, una hora. Pero eso también es cierto para los autos, por cierto. Solo en tales casos, yo mismo pensaría en la utilización de la CPU y el potencial de suspensión.

• La segunda razón es que realmente es muy difícil escribir un programa que use el 100% de la CPU del SO (por ejemplo, en Windows). Además, las CPU modernas (normalmente) tienen al menos 2-4 núcleos. Por lo tanto, un algoritmo tradicional que tiende a usar el 100% de una CPU de un solo núcleo, ahora tiene solo el 50% en una CPU de doble núcleo (simplificado pero visto en escenarios reales).

• Además, el sistema operativo tiene el control sobre la CPU y no sobre su programa, por lo que si hay otras aplicaciones con la misma o mayor prioridad (cuál es el valor predeterminado), su programa solo obtendrá la mayor cantidad de CPU posible. Pero las otras aplicaciones no morirán de hambre. (Por supuesto, esta es solo la teoría simplificada y, por supuesto, la multitarea de Windows, Linux y otros no es perfecta, pero en general lo consideraría de verdad).

  

"Anteriormente tenía la impresión de que el 100% de uso de la CPU era   preferible para una operación intensiva o larga .. "

Sí, quédate con esto. Pero, por ejemplo, si espera y realiza un bucle para otro proceso, en otras palabras, no hace nada, no sería tan malo si Thread.Sleep () durara unos milisegundos en ese bucle, dándole tiempo adicional a los demás. Si bien no es necesario para un buen sistema operativo multitarea, resolví algunos problemas con esto, por ejemplo. para Windows 2000. (Eso NO significa, por supuesto, usar Sleep () en cálculos, por ejemplo ...

Tal degradación es teóricamente posible y se denomina " electromigration ". La electromigración depende de la temperatura, acelerando a medida que aumenta la temperatura. Si se trata de un problema práctico para las CPU modernas, está en discusión. Las prácticas modernas de diseño de VLSI compensan la electromigración y es más probable que los chips fallen por otras razones.

Habiendo dicho eso, la electromigración ocurre incluso a cargas y temperaturas normales , pero es lo suficientemente lento como para que un chip bien diseñado se vuelva obsoleto mucho antes de fallar, o falle a través de otro mecanismo primero.

La velocidad de la electromigración depende de la temperatura del chip, y la vida útil se duplica por cada (muy aproximadamente) 10 ° C. De hecho, esta es la base de una prueba llamada "HTOL" (vida de operación a alta temperatura), que mide el tiempo que tarda un chip en morir, por ejemplo, en 125 ° C. Un chip que funciona a 125 ° C fallará aproximadamente 100 veces más rápido que un chip que funcione a 55 ° C, por lo que si se diseña para durar al menos 10 años a 55 ° C, un chip puede fallar dentro de 1 mes a 125 ° C. Si se ejecuta a algo más razonable, como 85 ° C, tal chip aún fallará al menos 5-10 veces antes de lo que fue diseñado.

Por supuesto, las CPU generalmente se diseñan teniendo en cuenta las temperaturas más altas, por lo que generalmente pueden durar años a una operación de carga del 100% a 85 ° C, 24/7. Por lo tanto, le sugiero que no se preocupe por "desgastar" la CPU y solo se preocupe por si una carga del 100% es adecuada desde la perspectiva de la ingeniería de software.

Si está ejecutando su código en los clientes, la utilización del 100% de la CPU significa que las computadoras cliente en ese momento no se pueden usar para nada más que para tareas con mayor prioridad. Como la mayoría de las aplicaciones normalmente se ejecutan con prioridad predeterminada, los usuarios que usan esas computadoras notarán que se congelan las computadoras y no podrán hacer nada más en sus computadoras. Incluso si estamos hablando de ráfagas cortas, los usuarios que trabajen en algo todavía lo notarán.

Como han dicho otros, usted fue muy reservado acerca de la configuración, por lo que no puedo asegurarlo. Pero, si sus clientes son computadoras de escritorio, manténgase alejado de la utilización del 100% de la CPU. No debido a la degradación de la CPU, sino porque no es una buena forma de interrumpir a los usuarios durante su trabajo.

Entonces, la situación es la siguiente: tiene un código que se ejecuta durante cinco horas usando el 100% de todas las CPU, que se optimiza tanto como se puede, el propietario de la máquina está bien y la máquina no se puede utilizar durante cinco horas. y su colega afirma que sería mejor ejecutar su código en 6 horas usando el 83.33% de todas las CPU, ya que causa menos desgaste en la computadora.

Depende de la computadora que estés usando. Sé que un fabricante de computadoras rechazó las reparaciones en garantía dentro del tiempo de garantía en computadoras domésticas baratas que se usaron en un entorno científico que funcionaba 24/7. Claramente querían que el cliente comprara sus servidores más caros o computadoras "comerciales". Si tuvieron éxito, no lo sé.

Cada Mac que he tenido tiene en algún momento de su vida útil el código de ejecución al 100% del uso de la CPU durante días a la vez. En un caso, tuve que apagar la pantalla, porque no tenía el cargador original para una computadora portátil, y con 4 núcleos e hiperhilos, consumía más energía que la que tenía el cargador, por lo que la batería se agotó y, cuando llegó, ¡El 5 por ciento de la computadora redujo la velocidad del reloj hasta que la batería alcanzó el 10%! (Con la pantalla apagada, funcionó a toda velocidad durante varios días). En ningún caso, los efectos nocivos.

Así que con una computadora bien diseñada, tienes razón. Con una computadora barata y mal diseñada, su colega podría tener razón. Por otro lado, puede considerar el costo de su tiempo de espera en comparación con el costo de comprar una computadora de reemplazo.

Si puede, haga que su código sea una tarea de menor prioridad y asegúrese de mantener el subproceso de la CPU separado de la GUI. Entonces es posible que tenga una utilización del 100%, pero el usuario siempre puede ejecutar otras tareas y mantenerse atento. Por sí misma, una CPU está diseñada para seguir funcionando al 100% durante un tiempo o no se liberará. A menos que el usuario final haya realizado modificaciones serias y peligrosas en su hardware, no puede dañar nada.