Pour ajouter à la complexité, en principe chaque composant, chaque bloc fonctionnel du silicium du processeur consomme autant qu’il fasse un travail utile ou pas et cette consommation est directement liée à la fréquence de l’horloge. On peut réduire cette consommation on utilisant carrément pas un composant : si on ne fait pas de multiplication, le module multiplication ne consomme pas, ou en abaissant sa fréquence d’horloge : lorsque plus aucun processus n’utilise le processeur général on peut le détecter et passer à une fréquence d’horloge très basse. Dans tous les cas la consommation peut baisser et donc la chaleur dégagée (car tout part en chaleur en informatique) diminuer. Il suffit pour s’en convaincre d’écouter le ventilateur (à vitesse variable) monté sur le proc ou de le toucher rapidement du bout du doigt.
Certain OS, Linux par ex, diminue la fréquence d’horloge dans les situations, beaucoup plus fréquentesqu’on n’imagine y compris en nav , ou il n’y a rien à faire, d’autres OS continuent à pédaler à fond la caisse (windows, au moins il y a 10 ans, maintenant je ne sais plus). Au final il était courant, pour une même activité macroscopique (une même utilisation de l’ordinateur) sur une même config matérielle d’un PC portable, d’avoir 10 heures d’autonomie avec Linux et 2 ou 3 avec WXP.

Mais l’adéquation d’une config au problème à traiter, et c’est souvent ce à quoi on pense quand on parle de puissance, dépend de bien d’autres choses. Par exemple WXP( .vs. Linus ou MacOS) est très glouton en mémoire et à défaut il passe son temps (et sa puissance CPU, et son budget disque, et au final ses ampères-heures) à swapper, et le résultat est catastrophique (lenteur) en terme de performance même si tout se déroule bien si ce n’est la lenteur (ah, oui, bien sur, on a ajouté récemment ce tout petit processus de rien du tout ...)

A l’extrême on peut aussi se trouver dans des situations ou plus rien d’utile ne se produit, on a l’impression que le processeur est bloqué (gracefull degradation), et ça se termine en reboot (dans le chenal du four, c’est pas top)

Tout ça n’est pas du tout purement théorique comme on peut le constater (pas trop souvent) en nav lorsque brutalement plus rien d’utile n’est fait, et qu’on s’en rend compte pourquoi et comment avec un outil tel que procexp permettant de voir qu’on « pédale dans la semoule, et vite » ou regcleaner pour constater tous les petit process de rien du tout qu’on s’est laissé installé à l’insu de son plein gré.

Et pour dramatiser encore on peut constater que le rendement global d’un équipement s’écroule généralement très brutalement plutôt que graduellement/harmonieusement (on parle de courbe en genoux, d’effet de seuil) : jusque là tout allait bien sans diminution notable et d’un seul coup tout s’écroule et on ne sait pas revenir à la situation antérieure (sauf à changer la taille mémoire, le type de disque, ..., le type de processeur ; pas mal de sorcellerie ... )

En clair : on vit dangereusement : tout marchait bien, j’ai rien changé et plus rien ne marche bien ...
Et espérer s’en sortir en surdimensionnant largement tout (pas très onéreux et très efficace) c’est compter sans la perversité des nouvelles versions d’OS ou de logiciel qui vont allègrement goinfrer tout à l’occasion d’une nouvelle release

Ceci peut relancer le débat sur processeur dédié en charge d’une fonction précise .vs. processeur général en charge de tout. En tout cas c’est à assumer au niveau de la sécurité.