"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.