Pourquoi votre code ne devrait-il pas utiliser 100% de CPU? [fermé]


42

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 à forte utilisation doit être limité pour réduire l'usure, et non pas si l'efficacité de ma mise en œuvre est efficace.

Un collègue d’aujourd’hui a suggéré de ne pas viser une utilisation à 100% de l’UC sur mes processus de chargement de données, car «les UC modernes sont bon marché et se dégraderont rapidement à 100%».

Est-ce vrai? Et si oui, pourquoi? J'avais auparavant l'impression qu'une utilisation à 100% du processeur était préférable pour une opération intensive ou longue, et je ne pouvais pas trouver de sources respectables sur le sujet de toute façon.


6
En supposant que votre application soit la seule chose qui tourne sur la boîte, alors, à proprement parler, une utilisation du processeur à 100% n’est pas mauvaise en réalité, mais cela peut plutôt indiquer que vous pourriez faire mieux. Je n'ai pas beaucoup travaillé avec les applications de bureau, mais pour les applications Web, par exemple, je n'ai jamais vu d'application qui maximise la charge du processeur et le code utilisant ces cycles était vraiment optimal. Il y a toujours quelque chose qui ne va pas. Cependant, cela est dû au fait que, sur le Web, nous sommes souvent liés aux E / S, ainsi un problème de processeur semble inapproprié. Je suis sûr que votre application est différente.
Brandon

7
En outre, différents systèmes d'exploitation traitent ce cas différemment. Mon ordinateur Windows, par exemple, fonctionne très mal si le processeur est utilisé à 100%. D'autre part, j'ai vu un serveur Linux fonctionner à 100% de son processeur pendant plusieurs jours d'affilée et tout allait bien. (Bien que nous ayons publié un correctif quelques jours plus tard.)
Brandon

17
Vous voulez travailler aussi vite que possible sans trop vous gaspiller. Si vous utilisez 100% de la CPU pour faire des calculs utiles, c'est bien. Si vous utilisez 100% de la CPU dans des boucles inutiles, c'est un gaspillage.
nwp

10
Vous avez payé pour tout cela. Utilisez tout cela.
Brian Hooper

4
Cette question semble être hors sujet parce qu'il s'agit d'électronique et non de programmation.

Réponses:


59

Si le refroidissement est insuffisant, le processeur peut surchauffer. Mais tous (enfin, au moins tous les processeurs de PC modernes) disposent de divers mécanismes de protection thermique qui vont ralentir la vitesse d'horloge ou, en dernier ressort, être arrêtés.

Donc, oui, sur un ordinateur portable poussiéreux, une charge de 100% du processeur pourrait causer des problèmes temporaires, mais rien ne se cassera ou ne se "dégradera" (peu importe ce que cela signifie).

Pour les problèmes liés au processeur, une charge de 100% du processeur est la bonne voie à suivre.

En ce qui concerne la réactivité des applications, il s'agit d'un concept distinct de l'utilisation du processeur. Il est tout à fait possible d'avoir une application qui ne répond pas et utilise 1% du processeur, ou une application réactive utilisant 100% du processeur. La réactivité de l'interface utilisateur se résume à la quantité de travail effectué dans le thread d'interface utilisateur et à la priorité du thread d'interface utilisateur par rapport aux autres threads.


3
et l'OS peut même imposer une tranche de récupération pour les cœurs
phénomène de cliquet

8
Je pense que la vraie réponse est que la plupart des processus ne sont pas liés au processeur, mais plutôt aux entrées / sorties. C'est pourquoi nous vivons dans un monde où l'utilisation du processeur à 100% est anormale, du moins pour le calcul "général / générique".
Windfinder

4
@windfinder Je dirais que, pour "le calcul", atteindre 100% est assez standard, mais seulement tant que le "calcul" doit faire quelque chose avec les maths :) par exemple, le traitement des requêtes MySQL n'est pas un calcul pour moi;)
yo '

@tohecz - Dans le sens où je l'ai utilisé, le calcul signifie simplement le temps CPU. Ici, nous nous disputons simplement sur la terminologie. Pour moi, tout ce que le processeur fait est un calcul (il "calcule"). En tant que spécialiste des données, je dirai également que la plupart des mathématiques sont également liées aux entrées / sorties (au-delà des mathématiques les plus triviales). Dans le monde mathématique, vous passez beaucoup de temps à trouver un moyen de compresser / transférer efficacement les données vers votre processeur afin de maintenir l'utilisation du processeur aussi élevée que possible (tout en minimisant l'inefficacité du cache, bien sûr).
Windfinder

4
Anecdote concernant les "ordinateurs portables poussiéreux": pour mes expériences de mémoire de maîtrise, j'ai utilisé un ordinateur portable de 4 ans en tant que coureur. Utilisation du processeur 24/7 à 100% pendant environ 3 mois . Après cela, ledit ordinateur portable a été relégué au poste de serveur pendant 4 années supplémentaires avant d'abandonner le fantôme (probablement en raison d'un problème graphique déjà endommagé).
mikołak

15

Les programmes Windows (winforms / WPF) doivent rester réactifs à tout moment. Avec une mise en œuvre naïve d'un processus utilisant des ressources à 100% de l'unité centrale, il est trop facile de faire en sorte que votre programme, voire votre système, paraisse lent et suspendu.

Avec une bonne implémentation (par exemple: utilisez un thread séparé avec une priorité plus basse), cela ne devrait pas poser de problème.

Vous ne devriez pas vous inquiéter de la rupture de votre processeur plus tôt.


3
Bien sûr, les programmes qui effectuent des calculs à long terme ne devraient probablement pas être des applications winforms / wpf, mais des travaux par lots sans interface utilisateur. Cela les rend plus simples car ils n'ont pas besoin de se soucier d'avoir un thread d'interface utilisateur réactif et permet de les lancer via un planificateur de tâches, etc. Si une interface utilisateur est nécessaire, je recommanderais quand même l'application du programme de lancement dans un processus complètement séparé (qui peut rester réactif assez facilement; c'est suffisant pour éviter de bloquer l'attente du message d'état du travail par lots).
Jan Hudec

15

Il n’ya généralement aucun problème avec un programme utilisant 100% de l’UC alors qu’il fait un travail utile et ne prend pas le temps de prendre quelque chose de plus important . Si, par exemple, une plate-forme matérielle particulière n’est capable d’utiliser que 100% du processeur en continu pendant une seconde avant de devoir réduire à 50% pour éviter une surchauffe, il est généralement préférable pour une application qui a un travail utile à exécuter.de fonctionner aussi vite que possible et de laisser le processeur ou le système d'exploitation gérer toute limitation nécessaire plutôt que de laisser une application deviner à quelle vitesse elle devrait "s'exécuter". Si une application ou un thread a un travail à priorité basse qui serait utile mais pas toujours critique, il peut être utile que le système d'exploitation limite l'utilisation du processeur pour les tâches de 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 demander une priorité de thread faible.

Les plus grandes situations dans lesquelles il est mauvais d'utiliser 100% de la 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 même être retardé si l'effort gaspillé de vérifier si la tâche est terminée occupe des ressources de la CPU qui pourraient autrement être utilisées pour la tâche].

  • L'application redessine trop souvent l'affichage. 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 arriver que l’animation soit affichée à 120 images par seconde sans flou de mouvement, mais ne puisse pas être affichée proprement à des cadences plus basses sans l’ajouter. Si le rendu d'une image avec un flou directionnel prend beaucoup plus de temps que sans, le rendu à 120 ips sur du matériel qui le prend en charge ne serait en réalité pas plus coûteux que le rendu à une cadence plus lente avec flou directionnel. [Situation simple: une roue à 29 rayons tournant à un tour par seconde. À 120 ips, la roue semble tourner avec la vitesse et la direction appropriées; à 60fps,

Le premier est clairement reconnaissable comme étant mauvais. La seconde est un peu plus subtile. Si vous ciblez une plate-forme mobile, il peut être souhaitable dans certains cas de permettre aux utilisateurs de sélectionner la cadence d'images souhaitée pour l'animation, car certains utilisateurs ne se soucient peut-être pas de l'autonomie de la batterie mais souhaitent une animation de meilleure qualité, tandis que d'autres acceptent une qualité inférieure. animation en échange d'une meilleure autonomie de la batterie. Plutôt que de laisser l'application essayer de deviner où devrait se trouver le compromis, il peut être utile de laisser l'utilisateur le personnaliser.


10

"Les processeurs modernes ne sont pas chers et se dégradent rapidement à 100%".

Je ne pense pas que quiconque ait réellement abordé la partie "dégrader" de cette question. Les circuits intégrés se dégradent lorsque la température de la matrice dépasse les limites définies par le fabricant. Les circuits intégrés sont généralement conçus pour fonctionner jusqu'à 125 ° C , bien que chaque augmentation de 10 ° C réduit la durée de vie de 50%

Les processeurs n'ont pas toujours de régulation thermique. Ensuite, certains AMD Durons ont rencontré des problèmes (il aurait été possible d'en détruire un si ils fonctionnaient sans radiateur). Désormais, tous les processeurs de PC auront des capteurs de température intégrés qui alimenteront l’horloge du processeur et ralentiront l’horloge pour éviter les dommages. Vous constaterez peut-être que votre programme utilise 100% du processeur disponible, mais que le processeur ne tourne 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 de la CPU. Généralement, votre programme doit alterner entre faire les choses le plus rapidement possible et attendre, suspendu, pour un accès en entrée ou un accès au disque. Si possible, évitez les périodes d’attente et de spin-lock, mais par courtoisie envers le reste du système.

Windows et Linux ont tous les deux des systèmes "gouvernants" de CPU qui gèrent la performance et la gestion thermique. Comme cela est fait au niveau du système d'exploitation, il peut prendre en compte la consommation totale de la CPU du système. Il incombe au système d'exploitation de gérer le matériel et d'empêcher les programmes utilisateur de l'utiliser à mauvais escient. Il incombe au propriétaire du matériel de garder les ventilateurs propres et fonctionnels, et au fabricant de prévoir des dissipateurs et ventilateurs adéquats.

Il existe quelques cas où le refroidissement des appareils est insuffisant, mais un flot de retours indique aux fabricants de ne pas le faire.


Cette vidéo de l'explosion d'AMD Duron est probablement fausse. Votre déclaration sur la régulation thermique est toujours valable.
Sam

1
Hm, je l'ai sorti car je peux voir pas mal d'affirmations sur Google qu'il s'agissait de faux.
pjc50

3
Il est possible de surchauffer un processeur Intel Core moderne en écrivant un code qui pousse le moteur SSE et en désactivant délibérément la limitation du processeur dans le système d'exploitation. Il semble que les fabricants (même Intel eux-mêmes) définissent les exigences thermiques en se basant sur l'hypothèse qu'il n'est pas normal (possible?) De forcer le processeur à calculer les 4 bascules par cycle d'horloge revendiquées tout le temps. Lorsque quelqu'un parvient à écrire du code, son processeur commence à surchauffer. Voir: stackoverflow.com/questions/8389648/…
slebetman

^ "Il est possible qu'il soit possible d'en détruire un si on le lance sans radiateur" - j'ai "personnellement confirmé" qu'il était possible de détruire les anciens K7 sans radiateur .. ; c'est comme, presque 2 décennies en arrière? !!
user2864740

3

Pour jouer l’avocat du diable: En un sens, un programme qui ne peut pas atteindre une utilisation à 100% pourrait causer une usure plus grave: à moins qu’il soit suspendu dans l’attente d’une frappe, il est probable qu’il soit suspendu dans l’attente de la plupart du temps. Et les disques sont (encore généralement) de gros dispositifs mécaniques sujets à une usure mécanique ou à un risque de choc / d’effet gyroscopique lorsqu’ils se déplacent, sans parler de la consommation électrique.


Dans ce cas, il s'agit simplement d'un processus complexe sur un jeu de données volumineux (en mémoire), ce qui prend quelques minutes. Mais c'est certainement un bon point pour les autres lecteurs.
Nick Udell

3

"Les processeurs modernes ne sont pas chers et se dégradent rapidement à 100%".

Vous n'avez pas du tout à vous soucier de la "dégradation du processeur". Les processeurs modernes ne sont pas de moindre qualité que par le passé.

Il est très coûteux (et le devient de plus en plus cher tous les deux ans) de fabriquer des processeurs, mais des milliards de dollars pour construire une nouvelle usine ne sont pas rares (voir lien).

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

Les coûts de production d'un processeur dépendent au maximum du non. des 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, pas de lien nécessaire ici)

Je peux énumérer un certain nombre de raisons pour lesquelles j’estimerais que les processeurs modernes ont tendance à être de meilleure qualité qu’auparavant.

Mais seulement le plus important: les avantages des tests. L'électronique moderne est "conçue pour le test". Qu'il s'agisse de logiciel ou de matériel informatique, la perspicacité générale de la valorisation des tests par rapport à presque tout le reste n'est pas si ancienne. Pour les processeurs, les tests sont même effectués pour déterminer les différents types de prix et de fréquences, par exemple les meilleurs processeurs sont vendus avec les fréquences les plus élevées. Malgré cela, les transformateurs moins chers sont très souvent capables de fonctionner à 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 d'habitude aujourd'hui qu'avec plusieurs milliers de transistors d'un processeur des années soixante-dix. Mais cela ne contredit pas ma réponse, IMO. Les processeurs en général tendent à avoir de nombreuses erreurs connues, du moins dans le microcode, mais cela n’est pas sujet ici.)

Il y a encore plus de raisons de ne pas s'inquiéter de la dégradation du processeur de 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 processeur 100% 24h / 24 et 7j / 7 toute l'année, il mourra généralement plus tôt qu'un processeur utilisé uniquement toutes les deux semaines. Mais c'est vrai aussi pour les voitures. Ce n'est que dans de tels cas que je penserais à l'utilisation du processeur et au potentiel de dormir vous-même.

  • La deuxième raison est qu’il est vraiment très difficile d’écrire un programme qui utilise 100% du processeur de l’OS (par exemple sous Windows). De plus, les processeurs modernes ont (normalement) au moins 2 à 4 cœurs. Ainsi, un algorithme traditionnel qui tend à utiliser 100% d'un processeur simple cœur n'a maintenant que 50% sur un processeur double cœur (simplifié mais visible dans des scénarios réels).

  • De plus, le système d’exploitation contrôle le processeur et non votre programme. Par conséquent, s’il existe d’autres applications ayant une priorité identique ou supérieure (valeur par défaut), votre programme n’obtient que le plus de ressources 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, j’envisagerais cela comme vrai).

"J'avais auparavant l'impression qu'une utilisation à 100% du processeur était préférable pour une opération intensive ou longue .."

Oui, reste avec ça. Mais par exemple, si vous attendez et mettez en boucle un autre processus, c'est-à-dire que vous ne faites rien, ce ne serait pas trop mal si vous Thread.Sleep () quelques millisecondes dans cette boucle, laissant plus de temps aux autres. Bien que cela ne soit pas nécessaire pour un bon système d’exploitation multitâche, j’ai résolu certains problèmes, par exemple pour Windows 2000. (Cela ne signifie pas, bien sûr, que vous utilisiez Sleep () dans des calculs, par exemple.


3
Bien que cette réponse soit vraie aujourd'hui, il y a une préoccupation pour l'avenir. Auparavant, "l'état solide" signifiait la plus grande fiabilité, mais nous avons maintenant le flash MLC qui, dans certains cas, n'est prévu que pour 1 000 cycles d'effacement par bloc. Combien de temps avant la réduction de la taille des matrices produit un phénomène similaire pour les processeurs qui doivent fonctionner à 100% en permanence?
Michael

2
@ Michael, les processeurs ne sont pas en train de muter, ils écrivent dans une mémoire volatile, mais je comprends tout de même ce que vous essayez de dire.
Peter

3

Une telle dégradation est théoriquement possible et est appelée " é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 un sujet de débat. 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 à des températures normales , mais elle est suffisamment lente pour qu'une puce bien conçue devienne obsolète bien avant de tomber en panne, ou bien elle passe d'abord par un autre mécanisme.

Le taux d'électromigration dépend de la température de la puce, la durée de vie étant multipliée par deux par 10 ° C (très approximativement). C'est en fait la base d'un test appelé "HTOL" (durée de vie en fonctionnement à haute température), qui mesure le temps nécessaire pour qu'une puce meure à 125 ° C, par exemple. Une puce fonctionnant à 125 ° C échouera environ 100 fois plus rapidement qu'une puce fonctionnant à 55 ° C. Ainsi, si elle est conçue pour durer au moins 10 ans à 55 ° C, elle risque de tomber en panne dans un mois à 125 ° C. Si elle fonctionne à une température plus raisonnable, comme 85 ° C, une telle puce échouera au moins 5 à 10 fois plus tôt que prévu.

Bien entendu, les processeurs étant généralement conçus pour des températures plus élevées, ils peuvent durer des années à 85 ° C en mode de charge à pleine charge. Je vous suggère donc de ne pas vous soucier de "l’usure" du processeur, mais seulement de vous demander si une charge de 100% est appropriée du point de vue de l’ingénierie logicielle.


La recherche de ce mot a conduit à une recherche avec de nombreux résultats qui sont une bonne lecture sur le réseau SE ... dont beaucoup sont dans Electronics.SE et SuperUser.

1

Si vous exécutez votre code sur des clients, une utilisation de 100% de l'UC signifie que les ordinateurs clients de cette époque ne peuvent être utilisés que pour des tâches d'une priorité plus élevée. Comme la plupart des applications fonctionnent généralement avec une priorité par défaut, les utilisateurs de ces ordinateurs remarqueront le blocage de leur ordinateur et ne pourront plus le faire autrement. Même si nous parlons de courtes rafales, les utilisateurs travaillant sur quelque chose le remarqueront quand même.

Comme d'autres l'ont dit, vous étiez assez secret sur la configuration, donc je ne peux pas le dire avec certitude. Toutefois, si vos clients sont des ordinateurs de bureau, éloignez-vous de l'utilisation à 100% de l'UC. Pas à cause de la dégradation du processeur, mais parce que ce n'est pas une bonne forme pour perturber les utilisateurs pendant leur travail.


6
Windows fonctionne de cette façon. Sous Linux et de nombreux autres systèmes, les threads qui attendaient quelque chose (entrée utilisateur) ont automatiquement la priorité sur les threads utilisant leur temps alloué, de sorte que les programmes interactifs restent réactifs même lorsque vous ne jouez pas avec les priorités.
Jan Hudec

2
@ JanHudec Windows fait réellement cela. superuser.com/questions/194223/…
NtscCobalt

@NtscCobalt: Oui. Qu'est-ce qui ne semble pas être Windows CE? Et Windows a de sérieux problèmes chaque fois qu'un processus est lourd sur le disque, mais c'est évidemment quelque chose de différent (la gestion du disque est plutôt médiocre dans Windows en général).
Jan Hudec

1

La situation est la suivante: vous avez du code qui s'exécute pendant cinq heures en utilisant 100% de tous les processeurs, qui est optimisé au maximum, le propriétaire de la machine va bien, la machine étant inutilisable pendant cinq heures et votre collègue. Il serait préférable d’exécuter votre code en 6 heures avec 83,33% de l’ensemble des processeurs, car il produirait moins d’usure sur votre 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 les délais impartis pour des ordinateurs personnels bon marché utilisés dans un environnement scientifique fonctionnant 24h / 24 et 7j / 7. Ils souhaitaient clairement que le client achète leurs serveurs plus coûteux ou leurs ordinateurs "professionnels". S'ils ont réussi, je ne sais pas.

Chaque Mac que j'ai possédé a, à un moment de sa vie, un code d'exécution utilisant 100% de l'UC pendant des jours. 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 un hyper filetage, il consommait plus d'énergie que le chargeur fourni - la batterie s'est donc déchargée et 5% l'ordinateur ralentit la cadence jusqu'à ce que la batterie atteigne 10%! (Avec l'écran éteint, il a fonctionné à plein régime 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é mal conçu, votre collègue aura peut-être raison. D'autre part, vous pourriez considérer le coût de votre temps d'attente par rapport au coût d'achat d'un ordinateur de remplacement.


0

Si vous le pouvez, définissez votre code comme une tâche moins prioritaire et veillez à maintenir le thread à forte intensité de processeur séparé de l'interface graphique. Vous pouvez alors utiliser 100%, mais l'utilisateur peut toujours exécuter d'autres tâches et rester réactif. En soi, un processeur est conçu pour continuer à fonctionner à 100% pendant un certain temps, sinon il ne serait pas libéré. À moins que l'utilisateur final ait apporté des modifications sérieuses et dangereuses à son matériel, vous ne pouvez rien endommager.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.