Personnellement, je me demande comment ça se fait que, de nos jours, on n'imagine pas le processeur en même temps que le logiciel qui va tourner dessus.
Oui enfin c'est un peu facile comme remarque. Pendant environ 20 ans, on a eu droit à la loi de Moore « facile », celle qui transformait « pour une surface donnée, on va doubler le nombre de transistors tous les 18 ou 24 mois » en « on va doubler la fréquence d'horloge des microprocesseurs tous les 18 à 24 mois ». Maintenant qu'on ne peut plus faire ça, on (re)passe au parallélisme (qu'on croyait être la panacée dans les années 70 et 80, et qui avait été déclaré mort et enterré pour l'usage générique dans les années 90 jusqu'en 2005). Donc pendant 20 ans, le hardware grand public accélérait plus ou moins automatiquement l'exécution d'applications, parfois sans même avoir besoin de recompiler. Bien sûr il y avait quelques trucs supplémentaires ici et là (AltiVec, 3dNow!, MMX, puis SSE, AVX) pour écrire des applications qui pouvaient spécifiquement viser certains types de codes (comme les instructions AES pour SSE4), mais globalement tout était pépère pour des applications « grand public ».
Pour les gens qui écrivent des applications dans un environnement où les ressources sont très limitées (en gros les applications de calcul scientifique/calcul intensif et les applications embarquées), chaque nouvelle version d'un processeur a tendance à rajouter son lot de comportements qui perturbent fortement les performances. Comme les compilateurs ont tendance à évoluer relativement lentement, on se retrouve à faire des optimisations à la main, et qui souvent devront être refaites/modifiées pour la prochaine génération de processeurs.
Et la raison pour tout ça, c'est qu'il y a deux facteurs de ralentissement pour l'optimisation automatique de code (en utilisant un compilateur) :
Entre le moment où une technique/un algorithme/etc. pour l'optimisation de code est publiée quelque part et le moment où elle est mise en œuvre dans des compilateurs en production, il se passe environ 10 ans. Le hardware n'y est pour rien. Par exemple, une version efficace de la représentation de programmes sous forme SSA (Static Single Assignment) a été proposée en 1989. Elle a été mise en œuvre dans des compilateurs de prod' vers 1997 si je ne me trompe pas (dans open64 de SGI), et dans GCC pas avant la v3.5, soit vers 2003-2004.
Entre le moment où le hardware expose de nouvelles fonctionnalités, que ce soit des instructions vectorielles (MMX/SSE/AVX), l'utilisation de prédicats pour exécuter du code spéculativement (sur processeurs Itanium ou ARM), les instructions de préchargement mémoire, ou même comme plus récemment, une version limitée de mécanismes de mémoire transactionnelle (sur certains modèles du Haswell d'Intel, ou bien pour les processeurs de Blue Gene Q), et le moment où elle peut être exploitée automatiquement, il se passe entre 5 et 10 ans. Par exemple, la génération automatique d'instructions vectorielles sur GCC a été considérée comme expérimentale jusque vers GCC v4.3 je crois bien (je peux me tromper). Pire, elle reste extrêmement restreinte comparée à l'implémentation d'Intel dans ICC.
Bref, le temps qu'un compilateur exploite correctement les features d'une archi, celle-ci a le temps de devenir dépassée (c'est quasiment le cas avec l'Itanium 2 par exemple).
Et oui, il y a un gros effort à faire pour faire communiquer les architectes et les développeurs de compilateurs et autres bibliothèques haute performance. D'ailleurs, un bon moyen d'obtenir des sous pour la recherche aux USA et en UE depuis environ 2009-2010, c'est de parler de co-design, en montrant qu'on associe des mecs du hardware et des mecs du software pour faire un système informatique avec un modèle d'exécution parallèle qui tient la route (càd : une vraie sémantique parallèle, un modèle mémoire qui permette les optimisations tout en assurant que les programmes s'exécutent correctement, et un modèle de synchronisation qui relie modèle de concurrence et modèle mémoire de façon cohérente).
[^] # Re: Sceptique...
Posté par lasher . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 10.
Oui enfin c'est un peu facile comme remarque. Pendant environ 20 ans, on a eu droit à la loi de Moore « facile », celle qui transformait « pour une surface donnée, on va doubler le nombre de transistors tous les 18 ou 24 mois » en « on va doubler la fréquence d'horloge des microprocesseurs tous les 18 à 24 mois ». Maintenant qu'on ne peut plus faire ça, on (re)passe au parallélisme (qu'on croyait être la panacée dans les années 70 et 80, et qui avait été déclaré mort et enterré pour l'usage générique dans les années 90 jusqu'en 2005). Donc pendant 20 ans, le hardware grand public accélérait plus ou moins automatiquement l'exécution d'applications, parfois sans même avoir besoin de recompiler. Bien sûr il y avait quelques trucs supplémentaires ici et là (AltiVec, 3dNow!, MMX, puis SSE, AVX) pour écrire des applications qui pouvaient spécifiquement viser certains types de codes (comme les instructions AES pour SSE4), mais globalement tout était pépère pour des applications « grand public ».
Pour les gens qui écrivent des applications dans un environnement où les ressources sont très limitées (en gros les applications de calcul scientifique/calcul intensif et les applications embarquées), chaque nouvelle version d'un processeur a tendance à rajouter son lot de comportements qui perturbent fortement les performances. Comme les compilateurs ont tendance à évoluer relativement lentement, on se retrouve à faire des optimisations à la main, et qui souvent devront être refaites/modifiées pour la prochaine génération de processeurs.
Et la raison pour tout ça, c'est qu'il y a deux facteurs de ralentissement pour l'optimisation automatique de code (en utilisant un compilateur) :
Et oui, il y a un gros effort à faire pour faire communiquer les architectes et les développeurs de compilateurs et autres bibliothèques haute performance. D'ailleurs, un bon moyen d'obtenir des sous pour la recherche aux USA et en UE depuis environ 2009-2010, c'est de parler de co-design, en montrant qu'on associe des mecs du hardware et des mecs du software pour faire un système informatique avec un modèle d'exécution parallèle qui tient la route (càd : une vraie sémantique parallèle, un modèle mémoire qui permette les optimisations tout en assurant que les programmes s'exécutent correctement, et un modèle de synchronisation qui relie modèle de concurrence et modèle mémoire de façon cohérente).