C'est marrant, tu as exactement le point de vue du côté hardware : croire que c'est en faisant des améliorations matérielles qu'on arrivera à avoir des performances.
Ce n'est absolument pas ce que je sous-entends. Et je ne dis absolument pas que les mecs du hardware sont les « gentils », et les mecs du soft les « méchants ». Je suis un mec du soft moi-même, et il se trouve que j'ai bossé (et je continue de bosser en fait) beaucoup avec les gens de la compilation, mais aussi avec des architectures pour les processeurs.
Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur, il tique. En gros, l'idée de notre projet est de justement exposer le plus de trucs en hard au logiciel, pour le que le logiciel fasse ce qu'il veut/peut avec. Ensuite, les mecs des compilateurs/runtimes retournent parler avec les architectures/mecs du hard, et leur disent ce qui définitivement nécessite d'être mis en œuvre en matériel, et ce que le logiciel peut faire efficacement sans aide matérielle.
Le point de vue que j'expose est aussi celui de pas mal de chercheurs en compilation : en gros, on a des techniques, on démontre qu'elles fonctionnent soit expérimentalement, du genre « je te donne mon algo, mais pour mes expériences j'ai tout transformé à la main », soit tu fais quelque chose de relativement théorique du genre « tiens, voilà mon algo, qui est en complexité polynomiale, et je fais la preuve qu'il est correct ». De temps en temps, tu as des mecs qui l'implémentent pour de vrai dans leurs compilateurs (heureusement). Mais je dirais que c'est du 1⁄3/1⁄3/1⁄3 en termes de proportions quand tu lis les papiers de recherche. À ceci il faut rajouter que l'implémentation n'est pas nécessairement disponible (parce qu'elle est faite dans un compilateur proprio), ce qui force donc le mec qui veut mettre en œuvre la technique de découvrir par lui-même tout ce qui n'a pas été dit. Parfois, ce qui fait qu'une technique fonctionne bien tient autant à l'algorithme qu'aux subtilités d'implémentation.
C'est par exemple ce qui s'est passé pour le papier sur la forme SSA : le papier était le premier à proposer un algorithme utilisable (i.e. en temps polynomial) pour exploiter SSA. Le truc, c'est que même si tu as trouvé le bon algo, écrire un compilateur nécessite de choisir très soigneusement ses structures de données. Il existe des papiers qui tiennent plus de l'ingénierie que de la recherche, mais qui expliquent comment un algorithme (par ex, mise sous forme SSA, puis faire un « de-SSA ») est équivalent à l'original, mais plus simple, et donc plus facile à implémenter sans bug.
De plus, SSA en elle-même n'est pas une optimisation, mais elle permet d'obtenir une représentation du code qui permet les optimisations plus facilement.
Sinon, les chercheurs en compilation vont bien entendu aussi te dire que les mecs du hardware te sortent des features de leur chapeau, sans forcément penser à « l'interface », ce qui rend la tâche du dév. de compilateur pour le moins ardue (par exemple : toutes les options proposées par l'Itanium en font un processeur — au moins de recherche — génial, mais avec aucun moyen « facile » de les utiliser depuis des intrinsics).
Première raison, c'est que les principaux gains de performance qui ont lieu ne sont pas dû au matériel comme tu le sous-entends mais sont principalement le fait d'avancées algorithmiques (surtout dans le domaine du calcul scientifique auquel se destine le processeur dont nous parlons),
Pour le calcul scientifique, j'ai déjà dit ailleurs qu'entre deux générations de processeurs, il fallait souvent ré-adapter le code pour la nouvelle architecture (les timings étant différents pour certaines séquences d'instruction, la hiérarchie mémoire ayant changé, etc.), ce qui se fait évidemment de façon logicielle. Cependant, surtout dans le cas des x86, oui, la venue des moteurs out-of-order, couplée à la présence de préchargeurs mémoire en matériel fait que, très souvent, il n'est plus nécessaire d'insérer à la main les trucs du genre _mm_prefetch(address).
Enfin, il est évident que le choix de la bonne structure de donnée et du bon algorithme sont les sources fondamentales de performance. Ce qui est aussi évident cependant, c'est que si ton implémentation utilise le « bon » algorithme, mais que les constantes élidées de ton algo en O(N) ou O(N log N) sont trop grosses, au final pour beaucoup des programmes scientifiques en question et qui tournent sur des workstations ou des petits clusters, la différence avec des algos à la complexité moins bonne mais mieux optimisés sera minime. Même sur les gros calculateurs, si ton programme est visiblement mal optimisé, tu risques de te prendre un refus par ses admins, parce que le temps machine est précieux (et que ça bouffe en électricité).
La raison pour laquelle les architectes rajoutent des fonctionnalités en matériel est évidemment qu'elles sont considérées comme utiles par les mecs du soft. Les instructions AltiVec ou SSE sont limitées en termes d'utilité pour les programmes en général, mais pour écrire des BLAS efficaces, si tu n'utilises pas ces instructions sur PowerPC ou x86, tu perds potentiellement entre 20 et 50% de performance (je prends en compte le fait que ton code ne fera pas que des multiplications de matrices).
Deuxième raison, le compilateur ne fait pas tout. Oui, comme tu le dis, il faut avoir un modèle de programmation parallèle, et si le matériel pouvait éviter de figer le modèle, on s'en porterait mieux, ça permettrait de pouvoir tester plein de modèle et de choisir suivant les cas. C'est bien l'algorithmique parallèle qui va amener les principaux gains, et pour faciliter le travail algorithmique, une machine «simple» (au sens où on peut en avoir une abstraction simple, mais elle peut être très complexe en vrai) et prévisible, c'est mieux.
Ben je suis dans un groupe de recherche qui justement cherche à proposer un modèle d'exécution1 adapté aux manycores. En gros notre but est de fournir une sorte de vision un peu abstraite d'un « assembleur parallèle ». Ensuite, si tu veux continuer à utiliser OpenMP1, mais qu'il génère notre truc, on est très content aussi (il faut juste quelqu'un qui écrive le compilateur qui va bien ...).
Le gros problème est effectivement (comme je le disais dans un commentaire plus haut) un manque de communication entre les fabricants de processeurs/machines parallèles, et les gens des logiciels systèmes (OS, Runtime, compilateurs). La communauté scientifique en prend lentement conscience, à mesure que 50 000 machines parallèles voient le jour, chacune avec leur modèle d'exécution, chacune avec leur modèle de programmation.
[1] Je dis bien exécution et pas programmation. Par exemple, le modèle de von Neumann est un modèle d'exécution séquentiel.
[2] Voilà, ça c'est un modèle de programmation. :-) ... Bon, il a aussi un modèle d'exécution, mais c'est pas (trop) important pour le programmeur.
[^] # 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é à 4.
Ce n'est absolument pas ce que je sous-entends. Et je ne dis absolument pas que les mecs du hardware sont les « gentils », et les mecs du soft les « méchants ». Je suis un mec du soft moi-même, et il se trouve que j'ai bossé (et je continue de bosser en fait) beaucoup avec les gens de la compilation, mais aussi avec des architectures pour les processeurs.
Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur, il tique. En gros, l'idée de notre projet est de justement exposer le plus de trucs en hard au logiciel, pour le que le logiciel fasse ce qu'il veut/peut avec. Ensuite, les mecs des compilateurs/runtimes retournent parler avec les architectures/mecs du hard, et leur disent ce qui définitivement nécessite d'être mis en œuvre en matériel, et ce que le logiciel peut faire efficacement sans aide matérielle.
Le point de vue que j'expose est aussi celui de pas mal de chercheurs en compilation : en gros, on a des techniques, on démontre qu'elles fonctionnent soit expérimentalement, du genre « je te donne mon algo, mais pour mes expériences j'ai tout transformé à la main », soit tu fais quelque chose de relativement théorique du genre « tiens, voilà mon algo, qui est en complexité polynomiale, et je fais la preuve qu'il est correct ». De temps en temps, tu as des mecs qui l'implémentent pour de vrai dans leurs compilateurs (heureusement). Mais je dirais que c'est du 1⁄3/1⁄3/1⁄3 en termes de proportions quand tu lis les papiers de recherche. À ceci il faut rajouter que l'implémentation n'est pas nécessairement disponible (parce qu'elle est faite dans un compilateur proprio), ce qui force donc le mec qui veut mettre en œuvre la technique de découvrir par lui-même tout ce qui n'a pas été dit. Parfois, ce qui fait qu'une technique fonctionne bien tient autant à l'algorithme qu'aux subtilités d'implémentation.
C'est par exemple ce qui s'est passé pour le papier sur la forme SSA : le papier était le premier à proposer un algorithme utilisable (i.e. en temps polynomial) pour exploiter SSA. Le truc, c'est que même si tu as trouvé le bon algo, écrire un compilateur nécessite de choisir très soigneusement ses structures de données. Il existe des papiers qui tiennent plus de l'ingénierie que de la recherche, mais qui expliquent comment un algorithme (par ex, mise sous forme SSA, puis faire un « de-SSA ») est équivalent à l'original, mais plus simple, et donc plus facile à implémenter sans bug.
De plus, SSA en elle-même n'est pas une optimisation, mais elle permet d'obtenir une représentation du code qui permet les optimisations plus facilement.
Sinon, les chercheurs en compilation vont bien entendu aussi te dire que les mecs du hardware te sortent des features de leur chapeau, sans forcément penser à « l'interface », ce qui rend la tâche du dév. de compilateur pour le moins ardue (par exemple : toutes les options proposées par l'Itanium en font un processeur — au moins de recherche — génial, mais avec aucun moyen « facile » de les utiliser depuis des intrinsics).
Pour le calcul scientifique, j'ai déjà dit ailleurs qu'entre deux générations de processeurs, il fallait souvent ré-adapter le code pour la nouvelle architecture (les timings étant différents pour certaines séquences d'instruction, la hiérarchie mémoire ayant changé, etc.), ce qui se fait évidemment de façon logicielle. Cependant, surtout dans le cas des x86, oui, la venue des moteurs out-of-order, couplée à la présence de préchargeurs mémoire en matériel fait que, très souvent, il n'est plus nécessaire d'insérer à la main les trucs du genre
_mm_prefetch(address).Enfin, il est évident que le choix de la bonne structure de donnée et du bon algorithme sont les sources fondamentales de performance. Ce qui est aussi évident cependant, c'est que si ton implémentation utilise le « bon » algorithme, mais que les constantes élidées de ton algo en O(N) ou O(N log N) sont trop grosses, au final pour beaucoup des programmes scientifiques en question et qui tournent sur des workstations ou des petits clusters, la différence avec des algos à la complexité moins bonne mais mieux optimisés sera minime. Même sur les gros calculateurs, si ton programme est visiblement mal optimisé, tu risques de te prendre un refus par ses admins, parce que le temps machine est précieux (et que ça bouffe en électricité).
La raison pour laquelle les architectes rajoutent des fonctionnalités en matériel est évidemment qu'elles sont considérées comme utiles par les mecs du soft. Les instructions AltiVec ou SSE sont limitées en termes d'utilité pour les programmes en général, mais pour écrire des BLAS efficaces, si tu n'utilises pas ces instructions sur PowerPC ou x86, tu perds potentiellement entre 20 et 50% de performance (je prends en compte le fait que ton code ne fera pas que des multiplications de matrices).
Ben je suis dans un groupe de recherche qui justement cherche à proposer un modèle d'exécution1 adapté aux manycores. En gros notre but est de fournir une sorte de vision un peu abstraite d'un « assembleur parallèle ». Ensuite, si tu veux continuer à utiliser OpenMP1, mais qu'il génère notre truc, on est très content aussi (il faut juste quelqu'un qui écrive le compilateur qui va bien ...).
Le gros problème est effectivement (comme je le disais dans un commentaire plus haut) un manque de communication entre les fabricants de processeurs/machines parallèles, et les gens des logiciels systèmes (OS, Runtime, compilateurs). La communauté scientifique en prend lentement conscience, à mesure que 50 000 machines parallèles voient le jour, chacune avec leur modèle d'exécution, chacune avec leur modèle de programmation.
[1] Je dis bien exécution et pas programmation. Par exemple, le modèle de von Neumann est un modèle d'exécution séquentiel.
[2] Voilà, ça c'est un modèle de programmation. :-) ... Bon, il a aussi un modèle d'exécution, mais c'est pas (trop) important pour le programmeur.