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

Estoy hablando específicamente de un programa C # .NET 4 que se ejecuta en Windows XP o superior, pero las respuestas generales también son aceptables.

Asuma un programa ya optimizado y eficiente. El problema aquí se debe completamente a los efectos del alto uso de la CPU en el hardware, y si un programa de alto uso debe limitarse para reducir el desgaste, no si mi implementación es eficiente.

Un colega sugirió hoy que no debería aspirar al 100% de la utilización de la CPU en mis procesos de carga de datos porque "las CPU modernas son baratas y se degradarán rápidamente al 100% de la CPU".

¿Es esto cierto? Y si es así, ¿por qué? Anteriormente tenía la impresión de que el 100% de uso de la CPU era preferible para una operación intensiva o prolongada, y no pude encontrar ninguna fuente respetable sobre el tema de ninguna manera.

Si el enfriamiento es insuficiente, la CPU podría sobrecalentarse. Pero todos (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 con polvo, el 100% de la carga de la CPU podría 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 la 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 receptiva que usa 100% de CPU. La capacidad de respuesta de la interfaz de usuario se reduce a la cantidad de trabajo realizado en el hilo de la interfaz de usuario y la prioridad del hilo de la interfaz de usuario frente a otros hilos.

Los programas de Windows (winforms / WPF) siempre deben responder. Con una implementación ingenua de un proceso que utiliza recursos de CPU al 100%, es demasiado fácil hacer que su programa o incluso su sistema parezca lento y bloqueado.

Con una buena implementación (por ejemplo: use un hilo separado con menor prioridad) no debería ser un problema.

No debe preocuparse por que su CPU se rompa antes.

Por lo general, no hay nada de malo en que un programa use 100% CPU mientras que en realidad está haciendo un trabajo útil y no le quita tiempo a nada más importante . Si una plataforma de hardware en particular, por ejemplo, solo es capaz de usar 100% de CPU de forma continua durante un segundo antes de que tenga que volver al 50% para evitar el sobrecalentamiento, generalmente es mejor para una aplicación que tiene un trabajo útil para realizarpara ejecutarse tan rápido como sea posible, y dejar que la CPU o el SO manejen cualquier aceleración necesaria, en lugar de 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 sería útil pero no crítico en todo momento, puede ser útil para el sistema operativo limitar el uso de CPU de tareas de baja prioridad al 50%, de modo que si la CPU necesita 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 subproceso baja.

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

• La aplicación está ocupada esperando algún evento que no se acelerará mediante un sondeo persistente [y en realidad podría retrasarse si el esfuerzo desperdiciado en verificar si la tarea se realiza ocupa recursos de la CPU que de otro modo podrían gastarse haciendo la tarea].

• La aplicación vuelve a dibujar 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 podría mostrarse a 120 fps sin agregar desenfoque de movimiento, pero no podría mostrarse limpiamente a velocidades de cuadro más bajas sin agregarlo. Si renderizar un cuadro con desenfoque de movimiento llevaría mucho más tiempo que renderizarlo sin él, entonces renderizar a 120 fps en un hardware que lo admita no podría ser más costoso que renderizar a una velocidad de cuadro más lenta con desenfoque de movimiento. [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,

El primero es claramente reconocible como malo. El segundo es un poco más sutil. Si uno apunta a una plataforma móvil, puede ser conveniente en algunos casos permitir a los usuarios seleccionar la velocidad de fotogramas de la animación deseada, ya que algunos usuarios pueden no estar preocupados por la duración de la batería, pero desearían la mejor calidad de animación, mientras que otros aceptarían una calidad inferior animación a cambio de una mejor duración de la batería. En lugar de que la aplicación intente adivinar dónde debe estar la compensación, puede ser útil dejar 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 realmente la parte "degradar" de esta pregunta. Los circuitos integrados se degradarán cuando la temperatura de la matriz exceda los límites del fabricante. Los circuitos integrados generalmente están diseñados para operar hasta 125 ° C, aunque cada aumento de 10 ° C 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 disipador térmico). Ahora todos los procesadores de PC tendrán sensores de temperatura incorporados que retroalimentan el reloj de la CPU y reducirán la velocidad del reloj para evitar daños. Por lo tanto, es posible que su programa esté utilizando el 100% de la CPU disponible, pero la CPU solo funciona 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. En general, su programa debe alternar entre hacer las cosas lo más rápido posible y esperar, suspendido, la entrada o el acceso al disco. Debe evitar la espera ocupada y el bloqueo de giro si es posible, pero como cortesía para el resto del sistema.

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

Hay algunos casos en los que los dispositivos tienen un enfriamiento inadecuado, pero una avalancha de devoluciones les enseña a los fabricantes a no hacerlo.

Para jugar al abogado del diablo: en cierto modo, un programa que no puede alcanzar el 100% de utilización podría causar un desgaste peor: a menos que se suspenda la espera de una pulsación de tecla, es probable que se suspenda esperando la E / S del disco la mayor parte del tiempo. Y los discos son (todavía usualmente) grandes dispositivos mecánicos que están sujetos a desgaste mecánico o al riesgo de choque / 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 otros tiempos.

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

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

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 venderse (relativamente) "baratos" después de todo. (Creo que no es necesario un enlace aquí)

Puedo enumerar una serie de razones por las cuales consideraría que las CPU modernas tienden a ser de mayor calidad que en los "tiempos anteriores".

Pero solo lo más importante: Ventajas en las pruebas. La electrónica moderna está "diseñada para pruebas". Ya sea software o hardware, la idea general de valorar las pruebas sobre casi todo lo demás no es tan antigua. Para las CPU, las pruebas incluso se toman para formar los diferentes tipos de precios y frecuencias, por ejemplo, las mejores CPU se venden con las frecuencias más altas. A pesar de eso, los procesadores más baratos a menudo pueden operar con una frecuencia más alta que la vendida; 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 hoy en día que con unos miles de transistores de un procesador de los años setenta. Pero esto no contradice mi respuesta IMO. Procesadores en general tienden a tener muchos errores conocidos, al menos en microcódigo, pero esto no está sujeto aquí).

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

• La primera razón es que las CPU modernas disminuyen su frecuencia o aceleración si se calientan demasiado.

  Debe quedar claro que si utiliza la CPU 100% 24/7 durante todo el año, normalmente morirá antes de que una CPU solo se use cada dos semanas una hora. Pero eso también es cierto para los automóviles, por cierto. Solo en tales casos pensaría en la utilización de la CPU y el potencial duerme usted mismo.

• La segunda razón es que es realmente muy difícil escribir un programa que use el 100% de la CPU del sistema operativo (por ejemplo, en Windows). Además, las CPU modernas (normalmente) tienen al menos 2-4 núcleos. Entonces, 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 prioridad o más alta (cuál es la predeterminada), su programa solo obtendrá la mayor cantidad de CPU posible, pero las otras aplicaciones no lo harán. morir 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 cierto).

"Antes tenía la impresión de que era preferible utilizar el 100% de la CPU para una operación intensiva o prolongada ..."

Sí, quédate con esto. Pero, por ejemplo, si espera y realiza un ciclo para otro proceso, en otras palabras, no hace nada, no sería tan malo si Thread.Sleep () algunos milisegundos en ese ciclo, dando tiempo adicional a otros. 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 los cálculos, por ejemplo ...

Tal degradación es teóricamente posible y se llama " electromigración ". La electromigración depende de la temperatura, acelerando a medida que la temperatura aumenta. Si es un problema práctico para las CPU modernas está en debate. 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.

Dicho esto, la electromigración ocurre incluso a cargas y temperaturas normales , pero es lo suficientemente lenta como para que un chip bien diseñado quede obsoleto mucho antes de fallar, o falla primero a través de otro mecanismo.

La velocidad de electromigración depende de la temperatura del chip, y la vida útil se duplica por cada 10 ° C (aproximadamente). Esta es, de hecho, la base de una prueba llamada "HTOL" (vida operativa a alta temperatura), que mide cuánto tiempo tarda un chip en morir, digamos, 125 ° C. Un chip que funcione a 125 ° C fallará aproximadamente 100 veces más rápido que un chip que funcione a 55 ° C, por lo que si está diseñado para durar al menos 10 años a 55 ° C, un chip podría fallar dentro de 1 mes a 125 ° C. Si se ejecuta a algo más razonable como 85 ° C, dicho chip todavía fallaría 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 85 ° C 24/7 operación de carga del 100%. Por lo tanto, te sugiero que no te preocupes por "desgastar" la CPU y solo te preocupes si una carga del 100% es apropiada desde la perspectiva de la ingeniería de software.

Si está ejecutando su código en clientes, la utilización del 100% de la CPU significa que las computadoras cliente en ese momento no pueden usarse para otra cosa que no sean tareas con mayor prioridad. Como la mayoría de las aplicaciones generalmente se ejecutan con prioridad predeterminada, los usuarios que usan esas computadoras notarán la congelación de la computadora y no podrán hacer otra cosa en sus computadoras. Incluso si hablamos de ráfagas cortas, los usuarios que trabajan en algo aún lo notarán.

Como otros dijeron, usted era bastante reservado sobre la configuración, por lo que no puedo decir con certeza. Pero, si sus clientes son computadoras de escritorio, manténgase alejado de la utilización del 100% de la CPU. No por 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, por ejemplo, durante cinco horas con el 100% de todas las CPU, que está optimizado tanto como puede, el propietario de la máquina está bien con la máquina inutilizable durante cinco horas, y su colega afirma que sería mejor ejecutar su código en 6 horas utilizando el 83.33% de todas las CPU, ya que reduce el desgaste de la computadora.

Depende de la computadora que esté utilizando. Sé que un fabricante de computadoras rechazó las reparaciones de garantía dentro del tiempo de garantía en computadoras domésticas baratas que se utilizaron en un entorno científico que funciona las 24 horas, los 7 días de la semana. 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 código de vida útil al 100% de uso de 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 hiperprocesos utilizaba más energía que el cargador suministrado, por lo que la batería se apagó 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, ningún efecto negativo.

Entonces, 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 frente al costo de comprar una computadora de reemplazo.

Si puede, convierta su código en una tarea de menor prioridad y asegúrese de mantener el hilo pesado de la CPU separado de la GUI. Entonces puede tener una utilización del 100%, pero el usuario siempre puede ejecutar otras tareas y responder. Por sí sola, una CPU está diseñada para permanecer funcionando al 100% de uso por un tiempo, o no se liberaría. A menos que el usuario final haya realizado modificaciones serias y peligrosas en su hardware, no puede dañar nada.