Bonne question.
On ne cherche pas à cracher de l'assembleur pour tel ou tel processeur car
1/ C'est pas portable. Donc c'est stupide.
2/ Que le C est un langage qui peut être très bas niveau
3/ Que les vrais optimisations intéressantes sont des optimisations haut niveau. J'entend toujours Benoit me dire ("Dans les optims de bas niveau, c'est pas la peine, tout à été fait"). Une vrai optimisation intéressante, c'est détecté un if caché dans une résolution dynamique, dérursiver une récursive terminale, etc...
4/Enfin et surtout, que faire cracher de l'assembleur pour un processeur est un travail de fourmi !! C'est un travail qui prend un temps fou, il faut s"adapter à chaque architecture, et, en terme d'optimisation ça n'a quasiment aucun intérêt.
Cracher un assembleur correcte nécessite un travail énorme, faire des optimisations nécessite de maîtriser à fond les spec d'un processeurs.
Et à chaque fois, faut recommencer. C'est un travail énorme, à plein temps.
Le C, langage dans lequel tu peux contrôler énormément de choses, te permet de faire beaucoup d'optimisations bas niveau, ça suffit amplement.
Je t'invite à lire les articles de nicO dans LinuxMag pour t'en convaincre.
Conclusion : il est totalement stupide de faire un compilateur qui crache de l'assembleur alors que des gens (ceux qui font gcc) le font à notre place. Notre boulot, c'est de faire des optimisations haut niveau qui marchent sur tous les processeurs ! Pas la bidouille qui marche sur Athlon Barton, mais pas sur Athlon 64 X2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
On ne cherche pas à cracher de l'assembleur pour tel ou tel processeur car
1/ C'est pas portable. Donc c'est stupide.
2/ Que le C est un langage qui peut être très bas niveau
3/ Que les vrais optimisations intéressantes sont des optimisations haut niveau. J'entend toujours Benoit me dire ("Dans les optims de bas niveau, c'est pas la peine, tout à été fait"). Une vrai optimisation intéressante, c'est détecté un if caché dans une résolution dynamique, dérursiver une récursive terminale, etc...
4/Enfin et surtout, que faire cracher de l'assembleur pour un processeur est un travail de fourmi !! C'est un travail qui prend un temps fou, il faut s"adapter à chaque architecture, et, en terme d'optimisation ça n'a quasiment aucun intérêt.
Cracher un assembleur correcte nécessite un travail énorme, faire des optimisations nécessite de maîtriser à fond les spec d'un processeurs.
Et à chaque fois, faut recommencer. C'est un travail énorme, à plein temps.
Le C, langage dans lequel tu peux contrôler énormément de choses, te permet de faire beaucoup d'optimisations bas niveau, ça suffit amplement.
Je t'invite à lire les articles de nicO dans LinuxMag pour t'en convaincre.
Conclusion : il est totalement stupide de faire un compilateur qui crache de l'assembleur alors que des gens (ceux qui font gcc) le font à notre place. Notre boulot, c'est de faire des optimisations haut niveau qui marchent sur tous les processeurs ! Pas la bidouille qui marche sur Athlon Barton, mais pas sur Athlon 64 X2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker