Je continue à penser (mais peut être ais-je tord) que de nombreux mécanismes sont implémentés au sein du microprocesseur pour modifier le code que le compilateur n'a pas été capable d'optimiser tout seul.
L'échec de l'Itanium est patent sur ce point.
Un travail sur le code généré pour mieux exploiter les localité de code pourrait être largement améliorées si les compilateur avaient une meilleur connaissance sémantique du code (analyse de flot). Sachant que dans GCC, on peut préciser très précisément quel processeur on a en face, ce serait surement très profitable.
le problème viens aussi du côté bas niveau du code, faire comprendre à un compilateur la sémantique de
for(inti=0;i<N-2;i+=2){a[i+2]=f(i);}
n'est pas évident, mais possible tant qu'on ne fasse pas de magie avec l'arithmétique des pointeurs.
De là, il faut être capable de produire une IA capable de réécrire l'algorithme permettant de gérer ces blocs de lignes de cache, en étant sûr de la sémantique.
Cela suppose d'avoir un langage assez pur pour permettre d'être absolument sûr de ce qu'on fait.
Si un jour, on a ce genre d'outil, pléthore de transistors dédiés à modifier le code assembleur à la volée pourrait être consacré à faire un cœur de calcul de plus..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# De la nécessité de faire des incantations vaudou sur le code
Posté par Ontologia (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 8.
Je continue à penser (mais peut être ais-je tord) que de nombreux mécanismes sont implémentés au sein du microprocesseur pour modifier le code que le compilateur n'a pas été capable d'optimiser tout seul.
L'échec de l'Itanium est patent sur ce point.
Un travail sur le code généré pour mieux exploiter les localité de code pourrait être largement améliorées si les compilateur avaient une meilleur connaissance sémantique du code (analyse de flot). Sachant que dans GCC, on peut préciser très précisément quel processeur on a en face, ce serait surement très profitable.
le problème viens aussi du côté bas niveau du code, faire comprendre à un compilateur la sémantique de
n'est pas évident, mais possible tant qu'on ne fasse pas de magie avec l'arithmétique des pointeurs.
L'exemple d'une multiplication de matrice est typique : il faut éviter un parcours en long et en large et faire en sorte de "tiler" c'est à dire de construire des sous blocs rectangle et de paralléliser les calculs dessus.
De là, il faut être capable de produire une IA capable de réécrire l'algorithme permettant de gérer ces blocs de lignes de cache, en étant sûr de la sémantique.
Cela suppose d'avoir un langage assez pur pour permettre d'être absolument sûr de ce qu'on fait.
Si un jour, on a ce genre d'outil, pléthore de transistors dédiés à modifier le code assembleur à la volée pourrait être consacré à faire un cœur de calcul de plus..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker