Parce qu'il faut regarder les choses en face : plus ça va, plus de transistors sont utilisés pour "réécrire" du code mal écrit par le compilateur. Tous ces transistors consomment, et n'exécute pas du code, et mis ensemble permettrait surement de faire un coeur de plus, un dsp, du cache supplémentaire, que sais-je....
Regardes le succès des RISC par rapport au x86 (qui est compatible avec une archi de plusieurs dizaine d'année).
Un bon compilateur, du moment qu'il sache avec exactitude quel processeur cible il doit attaquer, est capable de préparer le out-of-order lui même.
Oui peux être dans un contexte monotache genre dsp, mais dans un contexte multitâche le compilo ne maîtrise pas du tout ce qui est en cache, quand le flow va être interrompu par un context switch, ...
[^] # Re: "scout" thread ?
Posté par M . En réponse au journal Sun Rock : Les détails arrivent. Évalué à 4.
Parce qu'il faut regarder les choses en face : plus ça va, plus de transistors sont utilisés pour "réécrire" du code mal écrit par le compilateur. Tous ces transistors consomment, et n'exécute pas du code, et mis ensemble permettrait surement de faire un coeur de plus, un dsp, du cache supplémentaire, que sais-je....
Regardes le succès des RISC par rapport au x86 (qui est compatible avec une archi de plusieurs dizaine d'année).
Un bon compilateur, du moment qu'il sache avec exactitude quel processeur cible il doit attaquer, est capable de préparer le out-of-order lui même.
Oui peux être dans un contexte monotache genre dsp, mais dans un contexte multitâche le compilo ne maîtrise pas du tout ce qui est en cache, quand le flow va être interrompu par un context switch, ...