Bon, peut-être qu'effectivement, icc est moins bon en -O2 contre gcc en -O2. Sauf que le -O3 existe aussi sur icc ! Faudrait p'tet essayer avec. Sans compter le fait qu'icc gère l'IPO (inter process optimization), qui permet de faire de l'inlining au moment du link (et plus au moment de la compilation des modules), ainsi que tout un tas d'autres trucs. Il y a aussi la pgo (profile guided optimization) qui permet, en "entraînant" icc, de compiler en fonction des jeux d'entrée d'un programme.
Bref, utiliser icc 9 sans utiliser l'option -fast (qui active -O3, -ipo, et une autre option dont je ne me souviens plus le nom) c'est pas très malin. Et je ne parle même pas de l'aide à la compilation qu'offre pgo.
Je bosse avec gcc et icc, et franchement, sur plate-forme intel, gcc a déjà du mal à faire aussi bien qu'ICC dans la plupart des cas où je l'utilise. :-)
Pour finir, ce qu'il est important de retenir, c'est que
« [...] on soulignera le fait qu'Intel optimise spécifiquement pour ses CPU + ne supporte pas une tétrachié d'architecture comme GCC + ne supporte pas autant de langages.»
La grande force de gcc c'est ça : il est multi-plate-forme, et supporte bien mieux les standards que ses concurrents. Il y a une contrepartie : écrire un backend optimisé pour une plate-forme spécifique demande beaucoup de travail, et j'ai cru comprendre qu'une centaine de personnes bossaient à plein temps sur icc (versions ia32 et ia64).
Pour gcc, certaines optimisations directement dépendantes de l'architecture (altivec pour powerpc par exemple, ou les instructions sse pour ia32) nécessitent qu'on se penche spécialement sur elles. Il faut de la main d'oeuvre, et je regrette un peu de ne pas être capable (en tout cas pas encore) de participer. :-)
Dernière chose :
«En définitive GCC s'améliore régulièrement et les devs semblent avoir fait le bon choix avec la technologie SSA.»
Déjà une remarque préliminaire : SSA existe depuis un bon bout de temps (j'ai encore quelque part un article datant de 1991, qui explique comment faire du SSA efficace), et est implémentée dans certains compilateurs propriétaires (MSVC++, ICC) depuis un moment.
En fait, les priorités de GCC n'étaient sans doute pas les mêmes auparavant (en tout cas c'est la seule explication que je vois) : au début, ils voulaient un compilo ISO-compliant, qui compile dans les règles de l'art, pour C (gcc 2.95), puis C++ (gcc 3.x), et les autres langages *accessoirement* (au début, il s'agissait bien de GNU C Compiler, et pas GNU Compiler Collection).
Avec la version 4.x, on peut *enfin* s'attaquer à l'optimisation (y'en avait déjà, mais c'était franchement désuet par rapport à ce que faisaient les concurrents).
Mais SSA n'aide pas à l'optimisation, du moins pas directement ! Ca permet de mieux repérer où faire des transformations, certes, mais c'est surtout utile pour l'allocation de registres, la détection de code mort, la propagation de constantes... Bref, ce n'est pas une « optimisation » en soi, mais plutôt un "faiseur" d'optimisation, dans le sens où si d'autres optims sont possibles, alors le compilateur pourra mieux les appliquer. SSA est donc la base d'un bon compilateur optimisant, il ne manque plus que les bonnes optimisations qui iront avec. :-)
# Houla, forcément, si on fait un icc -Ox uniquement...
Posté par lasher . En réponse au journal Benchmarks de GCC 4.1. Évalué à 10.
Bref, utiliser icc 9 sans utiliser l'option -fast (qui active -O3, -ipo, et une autre option dont je ne me souviens plus le nom) c'est pas très malin. Et je ne parle même pas de l'aide à la compilation qu'offre pgo.
Je bosse avec gcc et icc, et franchement, sur plate-forme intel, gcc a déjà du mal à faire aussi bien qu'ICC dans la plupart des cas où je l'utilise. :-)
Pour finir, ce qu'il est important de retenir, c'est que
« [...] on soulignera le fait qu'Intel optimise spécifiquement pour ses CPU + ne supporte pas une tétrachié d'architecture comme GCC + ne supporte pas autant de langages.»
La grande force de gcc c'est ça : il est multi-plate-forme, et supporte bien mieux les standards que ses concurrents. Il y a une contrepartie : écrire un backend optimisé pour une plate-forme spécifique demande beaucoup de travail, et j'ai cru comprendre qu'une centaine de personnes bossaient à plein temps sur icc (versions ia32 et ia64).
Pour gcc, certaines optimisations directement dépendantes de l'architecture (altivec pour powerpc par exemple, ou les instructions sse pour ia32) nécessitent qu'on se penche spécialement sur elles. Il faut de la main d'oeuvre, et je regrette un peu de ne pas être capable (en tout cas pas encore) de participer. :-)
Dernière chose :
«En définitive GCC s'améliore régulièrement et les devs semblent avoir fait le bon choix avec la technologie SSA.»
Déjà une remarque préliminaire : SSA existe depuis un bon bout de temps (j'ai encore quelque part un article datant de 1991, qui explique comment faire du SSA efficace), et est implémentée dans certains compilateurs propriétaires (MSVC++, ICC) depuis un moment.
En fait, les priorités de GCC n'étaient sans doute pas les mêmes auparavant (en tout cas c'est la seule explication que je vois) : au début, ils voulaient un compilo ISO-compliant, qui compile dans les règles de l'art, pour C (gcc 2.95), puis C++ (gcc 3.x), et les autres langages *accessoirement* (au début, il s'agissait bien de GNU C Compiler, et pas GNU Compiler Collection).
Avec la version 4.x, on peut *enfin* s'attaquer à l'optimisation (y'en avait déjà, mais c'était franchement désuet par rapport à ce que faisaient les concurrents).
Mais SSA n'aide pas à l'optimisation, du moins pas directement ! Ca permet de mieux repérer où faire des transformations, certes, mais c'est surtout utile pour l'allocation de registres, la détection de code mort, la propagation de constantes... Bref, ce n'est pas une « optimisation » en soi, mais plutôt un "faiseur" d'optimisation, dans le sens où si d'autres optims sont possibles, alors le compilateur pourra mieux les appliquer. SSA est donc la base d'un bon compilateur optimisant, il ne manque plus que les bonnes optimisations qui iront avec. :-)