Pourquoi votre code ne devrait-il pas utiliser 100% de CPU?
Je parle spécifiquement d'un programme C # .NET 4 fonctionnant sous Windows XP ou supérieur, mais les réponses générales sont également acceptables.
Supposons un programme déjà optimisé et efficace. Le problème ici est entièrement dû aux effets d'une utilisation élevée du processeur sur le matériel et à la question de savoir si un programme à haute utilisation doit être limité pour réduire l'usure, et non pas à savoir si mon implémentation est efficace.
Un collègue a suggéré aujourd'hui que je ne devrais pas viser une utilisation du processeur à 100% sur mes processus de chargement de données car "les processeurs modernes sont bon marché et se dégraderont rapidement à 100% du processeur".
Est-ce vrai? Et si oui, pourquoi? J'avais auparavant l'impression que l'utilisation du processeur à 100% était préférable pour une opération intensive ou longue, et je n'ai pu trouver aucune source respectable sur le sujet de toute façon.
Si le refroidissement est insuffisant, le processeur peut surchauffer. Mais tous (enfin, au moins tous les processeurs PC modernes) disposent de divers mécanismes de protection thermique qui ralentiront la vitesse d'horloge ou, en dernier recours, s'arrêteront.
Donc oui, sur un ordinateur portable poussiéreux, une charge de 100% du processeur peut causer des problèmes temporaires, mais rien ne se cassera ou ne "se dégradera" (quoi que cela signifie).
Pour les problèmes liés au processeur, une charge de 100% du processeur est la bonne solution.
Quant à la réactivité de l'application (UI), c'est un concept distinct de l'utilisation du processeur. Il est tout à fait possible d'avoir une application qui ne répond pas qui utilise 1% de CPU ou une application qui utilise 100% de CPU. La réactivité de l'interface utilisateur se résume à la quantité de travail effectuée dans le thread d'interface utilisateur et à la priorité du thread d'interface utilisateur par rapport aux autres threads.
Les programmes Windows (winforms/WPF) doivent à tout moment rester réactifs. Avec une implémentation naïve d'un processus qui utilise des ressources 100% cpu, il est trop facile de faire paraître votre programme ou même votre système lent et suspendu.
Avec une bonne implémentation (par exemple: utilisez un thread séparé avec une priorité inférieure), cela ne devrait pas poser de problème.
Vous ne devriez pas vous inquiéter de la rupture de votre processeur plus tôt.
Il n'y a généralement rien de mal avec un programme utilisant 100% CPU alors qu'il fait en fait un travail utile et ne prend pas de temps à quelque chose de plus important. Si une plate-forme matérielle particulière est par exemple seulement capable d'utiliser 100% CPU en continu pendant une seconde avant de devoir revenir à 50% pour éviter la surchauffe, il est généralement préférable pour une application qui a un travail utile à effectuer de fonctionner aussi vite qu'elle peut, et laisser le processeur ou le système d'exploitation gérer toute limitation nécessaire, que pour une application de deviner à quelle vitesse elle "devrait" fonctionner. Si une application ou un thread a un travail à faible priorité à faire qui serait utile mais pas à tout moment critique, il peut être utile pour le système d'exploitation de limiter l'utilisation du processeur des tâches à faible priorité à 50% de sorte que si le processeur doit le faire quelque chose rapidement, il sera prêt à "sprinter" pendant une seconde, mais l'application ne devrait pas s'inquiéter de telles choses au-delà de la demande d'une faible priorité de thread.
Les plus grandes situations où il est mauvais d'utiliser 100% de CPU sont les suivantes:
L'application est occupée à attendre un événement qui ne sera pas accéléré par une interrogation persistante [et pourrait en fait être retardé si l'effort gaspillé pour vérifier si la tâche est effectuée occupe des ressources CPU qui pourraient autrement être dépensées faisant la tâche].
L'application redessine l'affichage trop souvent. La définition de "trop souvent" dépendra dans une certaine mesure de la nature du dispositif d'affichage et du contenu affiché. Si le matériel d'affichage peut afficher 120 images par seconde, il peut y avoir des cas où l'animation peut être affichée à 120 images par seconde sans ajouter de flou de mouvement, mais ne peut pas être affichée correctement à des fréquences d'images inférieures sans l'ajouter. Si le rendu d'une image avec le flou de mouvement prendrait beaucoup plus de temps que le rendu sans, le rendu à 120 images par seconde sur le matériel qui le prend en charge ne pourrait en fait pas être plus coûteux que le rendu à une fréquence d'images plus lente avec le flou de mouvement. [Situation simple: une roue à 29 rayons, tournant à un tour par seconde. À 120 images par seconde, la roue semble tourner avec la bonne vitesse et la bonne direction; à 60 ips, une roue vacillante semble tourner lentement dans la direction opposée].
Le premier est clairement reconnaissable comme mauvais. Le second est un peu plus subtil. Si l'on cible une plate-forme mobile, il peut être souhaitable dans certains cas de permettre aux utilisateurs de sélectionner la fréquence d'images d'animation souhaitée, car certains utilisateurs peuvent ne pas s'inquiéter de la durée de vie de la batterie mais souhaiteraient la meilleure animation de qualité, tandis que d'autres accepteraient une qualité inférieure animation en échange d'une meilleure autonomie de la batterie. Plutôt que de faire en sorte que l'application essaie de deviner où le compromis devrait être, il peut être utile de laisser l'utilisateur le personnaliser.
"Les CPU modernes sont bon marché et se dégraderont rapidement à 100% CPU".
Je ne pense pas que quiconque ait réellement abordé la partie "dégrader" de cette question. Les CI se dégradent lorsque la température de la puce dépasse les limites du fabricant. Les circuits intégrés sont généralement conçus pour fonctionner jusqu'à 125 ° C, bien que chaque augmentation de 10 ° C raccourcit la durée de vie de 50%
Les processeurs n'avaient pas toujours de régulation thermique. Ensuite, certains AMD Durons ont rencontré des problèmes (il aurait été possible d'en détruire un s'il fonctionnait sans dissipateur thermique). Désormais, tous les processeurs PC auront des capteurs de température intégrés qui alimentent l'horloge du processeur et ralentiront l'horloge pour éviter tout dommage. Ainsi, vous pouvez constater que votre programme utilise 100% du processeur disponible, mais le processeur ne fonctionne qu'à 75% de sa vitesse nominale car son refroidissement est insuffisant.
Dans un programme utilisateur, ce n'est pas le bon endroit pour essayer de gérer la consommation du processeur. Généralement, votre programme doit alterner entre faire les choses le plus rapidement possible et attendre, suspendu, pour l'entrée ou l'accès au disque. Vous devriez éviter l'attente occupée et le verrouillage automatique si possible, mais par courtoisie envers le reste du système.
Windows et Linux ont tous deux des systèmes CPU "govenor" qui assureront la gestion des performances et de la chaleur. Étant donné que cela se fait au niveau du système d'exploitation, il peut représenter la consommation totale du processeur du système. Il est de la responsabilité du système d'exploitation de gérer le matériel et d'empêcher les programmes utilisateur de l'utiliser à mauvais escient. Il est de la responsabilité du matériel propriétaire de maintenir les ventilateurs propres et en état de marche, et le fabricant d'installer des dissipateurs de chaleur et des ventilateurs adéquats en premier lieu.
Il y a quelques cas où les appareils ont un refroidissement insuffisant, mais un flot de retours apprend aux fabricants à ne pas le faire.
"Les CPU modernes sont bon marché et se dégraderont rapidement à 100% CPU".
Vous n'avez pas du tout à vous soucier de la "dégradation du CPU". Les processeurs modernes ne sont pas de moins bonne qualité qu'auparavant.
Il est très cher (et devient plus cher tous les deux ans) de fabriquer des CPU, quelques milliards pour construire une nouvelle fab ne sont pas rares (voir lien).
http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant
Les coûts de production d'un CPU dépendent tout au plus du no. d'unités produites. C'est un fait bien connu en économie. C'est la raison pour laquelle ils peuvent être vendus (relativement) "bon marché" après tout. (Je pense, aucun lien n'est nécessaire ici)
Je peux énumérer un certain nombre de raisons pour lesquelles je considérerais que les processeurs modernes ont tendance à être de meilleure qualité que dans les "anciens temps".
Mais seulement le plus important: les avantages des tests. L'électronique moderne est "conçue pour le test". Qu'il s'agisse de logiciels ou de matériel, la vaste compréhension de l'évaluation des tests par rapport à presque tout le reste n'est pas si ancienne. Pour les CPU, les tests sont même effectués pour former les différents types de prix et de fréquence, par ex. les meilleurs processeurs sont vendus avec les fréquences les plus élevées. Malgré cela, les processeurs moins chers sont très souvent capables de fonctionner avec une fréquence plus élevée que celle vendue - ils ne sont paralysés que parce que le fabricant veut vendre des processeurs "de haut niveau" à des prix plus élevés.
(D'un autre côté, bien sûr, il y a plus d'erreurs possibles pour un processeur avec plus de 1,5 milliard de transistors comme normal aujourd'hui qu'avec quelques milliers de transistors d'un processeur des années 70. Mais cela ne contredit pas ma réponse IMO. Processeurs en général ont tendance à avoir beaucoup erreurs connues, au moins dans le microcode, mais ce n'est pas sujet ici.)
Il y a même plus de raisons de ne pas s'inquiéter de la dégradation du processeur pour votre programme:
La première raison est que les processeurs modernes diminuent leur fréquence ou leur accélération, s'ils deviennent trop chauds.
Il doit être clair que si vous utilisez le CPU à 100% 24h/24 et 7j/7 toute l'année, il mourra normalement plus tôt qu'un CPU utilisé uniquement toutes les deux semaines une heure. Mais cela est également vrai pour les voitures. Ce n'est que dans de tels cas que je penserais à l'utilisation du processeur et au sommeil potentiel.
La deuxième raison est qu'il est vraiment très difficile d'écrire un programme qui utilise 100% du CPU du système d'exploitation (par exemple sous Windows). En outre, les processeurs modernes ont (normalement) au moins 2 à 4 cœurs. Ainsi, un algorithme traditionnel qui a tendance à utiliser 100% d'un processeur simple cœur, n'a désormais que 50% sur un processeur double cœur (simplifié mais vu dans des scénarios réels).
De plus, le système d'exploitation a le contrôle sur le CPU et non sur votre programme, donc s'il y a d'autres applications avec une priorité identique ou supérieure (quelle est la valeur par défaut), votre programme ne reçoit que le plus de CPU possible, mais les autres applications ne le feront pas affamer. (Bien sûr, ce n'est que la théorie simplifiée, et bien sûr le multitâche de Windows, Linux et autres n'est pas parfait, mais dans l'ensemble je considérerais cela comme vrai).
"J'avais auparavant l'impression que l'utilisation du CPU à 100% était préférable pour une opération intensive ou longue .."
Oui, restez avec ça. Mais par exemple, si vous attendez et bouclez pour un autre processus, en d'autres termes ne faites rien, ce ne serait pas trop mal si vous Thread.Sleep () quelques millisecondes dans cette boucle, donnant plus de temps aux autres. Alors que ce n'est pas nécessaire pour un bon système d'exploitation multitâche, j'ai résolu certains problèmes avec cela, par exemple pour Windows 2000. (Cela ne signifie pas bien sûr d'utiliser Sleep () dans les calculs par exemple ..
Pour jouer l'avocat du diable: D'une certaine manière, un programme qui ne peut pas atteindre 100% d'utilisation pourrait entraîner une usure pire: à moins qu'il ne soit suspendu en attente d'une frappe, il est probable qu'il soit suspendu en attente d'E/S disque la plupart du temps. Et les disques sont (toujours généralement) de gros appareils mécaniques qui sont soumis à une usure mécanique ou au risque d'effets de choc/gyroscopiques lorsqu'ils se déplacent, sans parler de la consommation d'énergie.
Une telle dégradation est théoriquement possible et s'appelle " électromigration ". L'électromigration dépend de la température et s'accélère à mesure que la température augmente. Que ce soit un problème pratique pour les processeurs modernes est à débattre. Les pratiques de conception VLSI modernes compensent l'électromigration et les puces sont plus susceptibles d'échouer pour d'autres raisons.
Cela dit, l'électromigration se produit même à des charges et températures normales , mais elle est suffisamment lente pour qu'une puce bien conçue soit obsolète bien avant de tomber en panne, ou il échoue d'abord via un autre mécanisme.
Le taux d'électromigration dépend de la température de la puce, la durée de vie doublant pour chaque (très grossièrement) 10 ° C. C'est en fait la base d'un test appelé "HTOL" (durée de vie à haute température), qui mesure le temps qu'il faut à une puce pour mourir à, disons, 125 ° C. Une puce fonctionnant à 125 ° C échouera environ 100 fois plus rapidement qu'une puce fonctionnant à 55 ° C, donc si elle est conçue pour durer au moins 10 ans à 55 ° C, une puce peut échouer dans un délai d'un mois à 125 ° C. Si elle fonctionne à quelque chose de plus raisonnable, comme 85 ° C, une telle puce échouera toujours au moins 5 à 10 fois plus tôt qu'elle n'a été conçue.
Bien sûr, les processeurs sont généralement conçus avec des températures plus élevées à l'esprit, de sorte qu'ils peuvent généralement durer des années à 85 ° C 24/7, à 100% de charge. Je suggère donc que vous ne vous inquiétiez pas de "l'usure" du CPU, et que vous vous demandiez seulement si une charge à 100% est appropriée du point de vue de l'ingénierie logicielle.
Si vous exécutez votre code sur des clients, une utilisation à 100% du processeur signifie que les ordinateurs clients à ce moment-là ne peuvent pas être utilisés pour autre chose que des tâches de priorité plus élevée. Comme la plupart des applications s'exécutent généralement en priorité par défaut, les utilisateurs utilisant ces ordinateurs remarqueront le gel de l'ordinateur et ne pourront pas faire autrement sur leur ordinateur. Même si nous parlons de courtes rafales, les utilisateurs travaillant sur quelque chose le remarqueront toujours.
Comme d'autres l'ont dit, vous étiez assez discret sur la configuration, donc je ne peux pas dire avec certitude. Mais, si vos clients sont des ordinateurs de bureau, évitez d'utiliser 100% du processeur. Pas à cause de la dégradation du CPU, mais parce que ce n'est pas une bonne forme de perturber les utilisateurs pendant leur travail.
La situation est donc la suivante: vous disposez d'un code qui fonctionne, disons, pendant cinq heures en utilisant 100% de tous les processeurs, qui est optimisé autant que vous le pouvez, le propriétaire de la machine va bien avec la machine inutilisable pendant cinq heures, et votre collègue affirme qu'il serait préférable d'exécuter votre code en 6 heures en utilisant 83,33% de tous les processeurs, car cela réduit l'usure de l'ordinateur.
Cela dépend de l'ordinateur que vous utilisez. Je sais qu'un fabricant d'ordinateurs a refusé les réparations sous garantie dans le délai de garantie sur des ordinateurs personnels bon marché utilisés dans un environnement scientifique fonctionnant 24h/24 et 7j/7. Ils voulaient clairement que le client achète leurs serveurs ou ordinateurs "professionnels" plus chers. S'ils ont réussi, je ne sais pas.
Chaque Mac que j'ai possédé a à un moment donné son code de fonctionnement à 100% d'utilisation du processeur pendant des jours à la fois. Dans un cas, j'ai dû éteindre l'écran, car je n'avais pas le chargeur d'origine pour un ordinateur portable, et avec 4 cœurs et hyper threading, il utilisait plus d'énergie que le chargeur fourni - donc la batterie s'est déchargée et quand elle a atteint 5%, l'ordinateur a ralenti la vitesse d'horloge jusqu'à ce que la batterie atteigne 10%! (L'écran éteint fonctionnant à pleine vitesse pendant plusieurs jours). En aucun cas, aucun effet néfaste.
Donc, avec un ordinateur bien conçu, vous avez raison. Avec un ordinateur bon marché et mal conçu, votre collègue a peut-être raison. D'un autre côté, vous pourriez considérer le coût de votre temps d'attente par rapport au coût d'achat d'un ordinateur de remplacement.
Si vous le pouvez, faites de votre code une tâche de priorité inférieure et assurez-vous de garder le thread lourd CPU séparé de l'interface graphique. Ensuite, vous pourriez avoir une utilisation à 100%, mais l'utilisateur peut toujours exécuter d'autres tâches et rester réactif. En lui-même, un processeur est conçu pour continuer à fonctionner à 100% pendant un certain temps, sinon il ne serait pas publié. À moins que l'utilisateur final n'ait apporté des modifications sérieuses et dangereuses à son matériel, vous ne pouvez rien endommager.