Impact des compilateurs sur les architectures CPU x86/x64

Les compilateurs

Afin de réaliser notre dossier nous avons utilisé trois environnements de compilation différents : Visual Studio 2010 SP1, Intel C++ Compiler XE 12.0u5, et TDM-GCC (MinGW/GCC 4.6.1).

     Visual Studio 2010 SP1

L'environnement de développement de Microsoft est sans trop de surprise le plus répandu sous Windows. Côté optimisations, on notera que s'il propose la génération de code SSE, SSE2 et AVX (uniquement par l'ajout d'un switch en ligne de commande pour ce dernier, l'option n'est pas disponible dans l'interface de Visual Studio 2010), il ne propose pas de vectorisation automatique. Il ne propose pas non plus de dispatcher automatique.


Le compilateur intégré à Visual Studio (on l'appellera cl par la suite, du nom de son exécutable) est de loin le plus pointilleux au niveau de ce qu'il est capable de compiler. L'implémentation (très) partielle des standards C/C++ pose un certain nombre de problèmes d'interopérabilité avec les autres compilateurs. S'il existe de multiples éditions payantes, Microsoft propose depuis quelques années une version gratuite de Visual C++, baptisée Express. Elle est disponible en téléchargement  sur le site de Microsoft.

     Intel C++ Compiler XE 12.0u5

Intel propose lui aussi son propre compilateur sous Windows. Il repose en partie sur des composants réalisés par l'Edison Design Group  et très fortement customisés par Intel. D'un point de vue pratique, il a la particularité de s'intégrer facilement avec Visual Studio et de permettre de convertir facilement ses projets. On peut d'ailleurs passer à tout moment d'un compilateur à l'autre si l'on le souhaite ce qui est un très bon argument pour convaincre les développeurs de l'essayer.

Côté optimisation, ICC est extrêmement riche, en proposant entre autre la vectorisation automatique. Il est également capable de générer des builds ciblées pour différents niveaux de fonctionnalités de processeurs (les options QxSSE2, 3, 4.1, 4.2, AVX...) ainsi que réaliser une version dispatchée, mais pour un niveau donné uniquement. L'option QaxAVX par exemple fera tourner la version AVX de son code sur les processeurs compatibles AVX, et une version de base (SSE2) sur tous les autres processeurs.

En soit on peut comprendre l'intérêt de cette implémentation pour Intel : un programme compilé avec l'option QaxAVX fonctionnerait sur un processeur Sandy Bridge avec un code généré de manière optimale pour un processeur AVX (ce qui inclut le code généré pour la gestion des chaines de caractères et de la mémoire), et en mode SSE2 sur un Core i7 « Nehalem». Si l'on était taquin, nous dirions que cela permet pour certains benchmarks présentés par le constructeur dans certaines de ses présentations de creuser les écarts générationnels.


L'utilisation du compilateur d'Intel dans Visual Studio ne demande qu'un clic
L'autre problème de ces options est que contrairement à ce que sous entendent le nom des options, le compilateur d'Intel rajoute une vérification de la marque du processeur. C'était d'ailleurs l'un des problèmes évoqués par l'enquête de la FCC contre Intel. Une des conséquences (connues) de l'accord passé entre AMD, Intel et la FCC est que la documentation d'Intel regorge désormais d'avertissements sur le fait que les processeurs «non Intel» peuvent être traités différemment des processeurs Intel, sans plus de précisions. Nous allons tenter de voir en pratique si Intel a changé ses pratiques ou non. ICC a également la réputation d'être le compilateur le plus performant, une réputation que nous allons vérifier !

Notez enfin qu'ICC intègre un troisième mode d'optimisation (arch:SSE2 par exemple) qui permet de réaliser une build directement pour un niveau de fonctionnalité donné, et non plus pour un processeur Intel donné. La documentation de la version d'ICC que nous utilisions n'indiquait que le support de SSE4.1 au maximum pour cette option, SSE4.2 et AVX étant absent. Cependant, l'utilisation des paramètres arch:SSE4.2 et arch:AVX est bien possible La solution idéale ? En pratique pas forcément, comme nous le verrons rapidement.

ICC est un outil payant, proposé par Intel dans de nombreuses éditions , une version d'évaluation est cependant disponible.

     TDM-GCC (MinGW/GCC 4.6.1)

Issu du monde de l'Open Source, GCC est un compilateur dont la vocation historique tendait d'abord à l'universalité. Il existe ainsi pour toutes les architectures (même si cela ne veut pas dire qu'un même code sera compilable partout, des différences subtiles particulièrement autour de la gestion de la mémoire posent souvent problème lorsque l'on tente de réaliser du code "cross-compatible", par exemple qui soit compilable et sous ARM, et sous x86) et est disponible pour quasi tous les systèmes d'exploitations.

Pour pouvoir fonctionner sous Windows, GCC requiert un environnement de développement. Deux principaux sont disponibles, d'un côté Cygwin et de l'autre MinGW. Cygwin propose un environnement de développement POSIX complet qui permet de compiler un programme Unix et de le faire fonctionner sous Windows. Une implémentation qui n'est pas sans intérêt, mais qui a un coût pratique certain sur les performances. De nos jours les applications Open Source sous Windows se reposent principalement sur MinGW un environnement minimaliste pour Windows qui sert de pont entre GCC et l'OS, notamment en donnant accès à certaines DLL systèmes essentielles de Microsoft dont la fameuse msvcrt.dll, MS Visual C++ Runtime qui posait tant de problèmes sous Windows 95 et 98.


Cette DLL propose entre autre des implémentations pour les fonctionnalités standard de C/C++ (manipulation de chaines de caractères et d'espace mémoire). Dans le cas de la compilation d'un programme en C pur, ce sont ces routines Microsoft qui seront utilisées par le programme. La DLL étant très ancienne (1998), ses implémentations sont désuètes a l'égard des processeurs modernes ce qui désavantage assez sérieusement les programmes C compilés avec. Le problème ne se pose pas pour C++, GCC disposant dispose d'une bibliothèque standard pour ces fonctions. Il faudra garder en tête ce désavantage lorsque nous évaluerons les performances. Enfin, notez que si la volonté originale de GCC était l'universalité - ce qui lui a longtemps valu une réputation de performances moindres - depuis quelques temps les développeurs misent beaucoup sur les performances. On trouvera donc un grand nombre d'optimisations, de la vectorisation automatique à la génération de mathématiques SSE2 (AVX est partiellement géré) mais également des profils pour un grand nombre d'architectures x86. Nous avons utilisé pour ces tests la distribution TDM-GCC , plus à jour que la distribution originale. Elle inclut GCC en version 4.6.1.

Et AMD ?

Contrairement à Intel, AMD ne développe pas directement de compilateur. Cela ne veut pas dire que le constructeur ne travaille pas sur le sujet. D'abord, AMD participe (comme Intel) au développement de GCC. Microsoft travaille également activement avec AMD et Intel pour obtenir un support cohérent (et selon eux, non biaisé) dans leurs compilateurs, ainsi que pour les langages managés (.NET) ou des optimisations pour les deux marques existent également. Enfin, AMD sponsorise et distribue un fork d'Open64. Open64 était (en partie) issu d'un projet de recherche sur les compilateurs - financé par Intel - et ciblant son architecture Itanium. L'Itanium a en effet la particularité d'utiliser un jeu d'instruction VLIW. Chaque instruction en contient en réalité trois, qui seront exécutés par un groupe de trois unités scalaires. C'est donc au compilateur, pour Itanium, de choisir quelles instructions mixer pour obtenir le maximum de performances, une tâche particulièrement ardue.

Si Intel ne maintient plus ce projet, une version alternative d'Open64 continue d'être proposée par AMD. Elle n'est malheureusement disponible que sous Linux  ce qui limite son intérêt pour notre article.