Quelqu’un ici a-t-il comparé le compilateur Intel C ++ et GCC?

J’espère que cela aide plus que mal 🙂

Il y a un peu plus d’un an, j’ai fait une petite séance de compilation et je ne me souviens plus de rien.

1. GCC 4.2 (Apple)
2. Intel 10
3. GCC 4.2 (Apple) + LLVM

J’ai testé plusieurs programmes de traitement de signaux audio lourds que j’avais écrits.

Temps de compilation: Le compilateur Intel était de loin le compilateur le plus lent – plus que «2x fois plus lent», comme l’a indiqué un autre article.

GCC a très bien géré les modèles par rapport à Intel.

Le compilateur Intel a généré des fichiers d’objects volumineux.

GCC + LLVM a donné le plus petit binary.

Le code généré peut présenter des écarts importants en raison de la construction du programme et de la possibilité d’utiliser SIMD.

Pour ma façon d’écrire, j’ai trouvé que GCC + LLVM générait le meilleur code. Pour les programmes que j’ai écrits avant de prendre l’optimisation au sérieux (comme je l’ai écrit), Intel était généralement meilleur.

Les résultats d’Intel ont varié; il a bien mieux géré certains programmes, et certains programmes bien pire. Il a très bien géré le traitement brut, mais je donne le gâteau à GCC + LLVM car, mis dans le contexte d’un programme plus grand (normal), il a fait mieux.

Intel a été récompensé pour son travail sur des ensembles de données énormes.

GCC à lui seul génère le code le plus lent, même s’il peut être aussi rapide avec les mesures et les nano-optimisations. Je préfère les éviter car le vent peut changer de direction avec la prochaine version du compilateur, pour ainsi dire.

Je n’ai jamais mesuré de programmes mal écrits dans ce test (c.-à-d. Des résultats supérieurs aux dissortingbutions des bibliothèques de performances populaires).

Enfin, les programmes ont été écrits sur plusieurs années, en utilisant GCC comme compilateur principal à cette époque.

Mise à jour: J’autorisais également les optimisations / extensions pour Core2Duo. Les programmes étaient suffisamment propres pour permettre un aliasing ssortingct.

Il y a un PDF intéressant qui compare un certain nombre de compilateurs.

L’équipe MySQL a posté une fois que icc leur a donné environ 10% de gain de performance sur gcc. Je vais essayer de trouver le lien.

En général, j’ai trouvé que les compilateurs «natifs» fonctionnent mieux que gcc sur leurs plates-formes respectives

edit: J’étais un peu loin. Les gains typiques étaient de 20-30% et non de 10%. Certains boîtiers étroits ont doublé les performances. http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2004-Intel.pdf

Je suppose que cela varie en fonction du code, mais avec le code que je travaille actuellement, ICC 11.035 donne une amélioration presque deux fois supérieure à celle de gcc 4.4.0 sur un Xeon 5504.

Options icc: -O2 -fno-alias
options gcc: -O3 -msse3 -mfpmath=sse -fargument-noalias-global

Les options sont spécifiques au fichier contenant le code de calcul intensif, où je sais qu’il n’ya pas de crénelage. Code mono-thread avec une boucle nestede à 5 niveaux.

Bien que l’autovectorisation soit activée, aucun compilateur ne génère du code vectorisé (pas une faute des compilateurs)

Mise à jour (27/02/2015): en optimisant certains codes géophysiques (Q2, 2013) pour fonctionner sur Sandy Bridge-E Xeons, j’ai eu l’occasion de comparer les performances d’ICC 11.1 avec GCC 4.8.0, et GCC générait maintenant code plus rapide que ICC. Le code a utilisé des insortingnsèques AVX et a utilisé des instructions vectorisées à 8 voies (le compilateur nieither a autovectorisé le code correctement en raison de certaines exigences de disposition des données). De plus, l’implémentation LTO de GCC (avec le cœur IR intégré dans les fichiers .o) était beaucoup plus facile à gérer que dans ICC. GCC avec LTO fonctionnait environ 3 fois plus vite que ICC sans LTO. Je ne suis pas en mesure de trouver les chiffres pour GCC sans LTO, mais je me souviens que c’était encore plus rapide qu’ICC. Il ne s’agit en aucun cas d’une déclaration générale sur la performance d’ICC, mais les résultats ont été suffisants pour que nous puissions aller de l’avant avec GCC 4.8. *.

Dans l’attente de GCC 5.0 ( http://www.phoronix.com/scan.php?page=article&item=gcc-50-broadwell )!

Nous utilisons le compilateur Intel sur notre produit (DB2), sous Linux et Windows IA32 / AMD64, et sous OS X (c’est-à-dire tous nos ports de plate-forme Intel sauf SunAMD).

Je ne connais pas les chiffres, mais la performance est assez bonne pour que nous:

• payer pour le compilateur que je suis dit est très cher.
• vivre avec des temps de construction deux fois plus lents (principalement en raison du temps passé à acquérir des licences avant de pouvoir s’exécuter).

PHP – La compilation à partir de sources, avec ICC plutôt que GCC, devrait entraîner une amélioration de la vitesse de 10 à 20% – http://www.papelipe.no/tags/ez_publish/benchmark_of_intel_comstackd_icc_apache_php_and_apc

MySQL – La compilation à partir de sources, avec ICC plutôt que GCC, devrait entraîner une amélioration de la vitesse de 25% à 50% – http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2005-Intel.pdf

J’avais l’habitude de travailler sur un système de traitement du signal assez important qui fonctionnait sur un grand cluster. Nous avions l’habitude de compter sur de gros calculs mathématiques, le compilateur Intel nous a donné environ 10% moins de charge processeur que GCC. C’est très peu scientifique, mais c’était notre expérience (c’était il y a environ 18 mois).

Ce qui aurait été intéressant, c’est si nous pouvions également utiliser les bibliothèques mathématiques d’Intel, qui utilisent plus efficacement leur chipset.

J’ai utilisé UnixBench (v. 5.1.3) sur un openSUSE 12.2 (kernel 3.4.33-2.24-default x86_64) et l’ai compilé d’abord avec GCC, puis avec le compilateur d’Intel.

Avec 1 copie parallèle, UnixBench compilé avec Intel est environ 20% plus rapide que la version compilée avec GCC. Cependant, cela cache des différences énormes. Dhrystone est environ 25% plus lent avec le compilateur Intel, tandis que Whetstone s’exécute 2 fois plus rapidement.

Avec 4 copies d’UnixBench s’exécutant en parallèle, l’amélioration du compilateur Intel sur GCC n’est que de 7%. Encore une fois, Intel est bien meilleur chez Whetstone (> 200%) et plus lent chez Dhrystone (environ 20%).

De nombreuses optimisations effectuées régulièrement par le compilateur Intel nécessitent une syntaxe source spécifique et l’utilisation de -O3 -ffast-math pour gcc. Malheureusement, le composant -funsafe-math-optimizations de -ffast-math -O3 -march = native s’est révélé incompatible avec -fopenmp. Je dois donc diviser mes fichiers sources en groupes nommés avec les différentes options de Makefile. Aujourd’hui, j’ai rencontré une défaillance dans laquelle une version g ++ utilisant -O3 -ffast-math -fopenmp -march = native était capable d’écrire sur l’écran mais pas de la redirect vers un fichier. Une des différences les plus flagrantes à mon avis est l’optimisation par icpc uniquement de std :: max et min où gcc / g ++ veut que fmax | min [f] avec -ffast-math change sa signification par rapport à standard.