Plus je lis de docs, posts, débat, sur ces techniques d'incantations vaudoo sur le code, plus j'ai l'impression qu'on ferait mieux de s'attarder sur le compilateur. Ceux qui me connaissent me voient venir, mais c'est plus général comme problème :
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....
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.
Alors après, comment gérer le multitâche, la gestion d'état de celui-ci ? Je ne sais pas jusqu'où le compilateur peut aller, mais surement beaucoup plus loin qu'actuellement.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: "scout" thread ?
Posté par Ontologia (site web personnel) . En réponse au journal Sun Rock : Les détails arrivent. Évalué à 5.
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....
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.
Alors après, comment gérer le multitâche, la gestion d'état de celui-ci ? Je ne sais pas jusqu'où le compilateur peut aller, mais surement beaucoup plus loin qu'actuellement.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker