L'augmentation des besoins en mémoire a d'autres effets sur la consommation que la simple consommation des barrettes de RAM (qui de toutes façons ont tout le temps leurs cellules rafraîchies qu'elles soient utilisées ou non, cf les cold boot attacks & co, et donc consomment quasiment tout le temps la même chose).
Non, l'augmentation des besoins en mémoire fait surconsommer le CPU pour la raison suivante (bien décrite par le post d'alenvers) : la gestion de la mémoire, oui, mais la mémoire cache.
Dans le cas du cache de niveau 1, généralement segmenté en deux sous-caches, instructions et données, le code compilé réside intégralement dans le cache instruction là où le code interprété sépare l'interpréteur dans le cache instruction et le (éventuellement byte)code dans le cache données. Soit une surconsommation du cache données avant même de toucher aux données réelles manipulées par le programme.
Quand on sait ensuite que les accès au cache de second niveau se comptent en trentaines de cycles au minimum, il ne faut pas longtemps pour comprendre que la surpression sur le cache L1 entraîne un surnombre de cycles inutiles rien que pour la gestion des données réelles du programme !
Et ceci est totalement indépendant des calculs supplémentaires induits par l'interprétation des instructions (décoder en soft des instructions alors qu'un processeur fait ça très bien en matériel pour son langage induit également une perte de temps énorme). Le goulot d'étranglement des processeurs modernes réside dans les accès à la mémoire, pas dans le calcul.
[^] # Re: La différence principale entre php et c++
Posté par khivapia . En réponse au journal On n'est pas vendredi et pourtant : impact environnemental de nos langages. Évalué à 3.
Non, l'augmentation des besoins en mémoire fait surconsommer le CPU pour la raison suivante (bien décrite par le post d'alenvers) : la gestion de la mémoire, oui, mais la mémoire cache.
Dans le cas du cache de niveau 1, généralement segmenté en deux sous-caches, instructions et données, le code compilé réside intégralement dans le cache instruction là où le code interprété sépare l'interpréteur dans le cache instruction et le (éventuellement byte)code dans le cache données. Soit une surconsommation du cache données avant même de toucher aux données réelles manipulées par le programme.
Quand on sait ensuite que les accès au cache de second niveau se comptent en trentaines de cycles au minimum, il ne faut pas longtemps pour comprendre que la surpression sur le cache L1 entraîne un surnombre de cycles inutiles rien que pour la gestion des données réelles du programme !
Et ceci est totalement indépendant des calculs supplémentaires induits par l'interprétation des instructions (décoder en soft des instructions alors qu'un processeur fait ça très bien en matériel pour son langage induit également une perte de temps énorme). Le goulot d'étranglement des processeurs modernes réside dans les accès à la mémoire, pas dans le calcul.