Discussion :

[Charlemagne]

Si vous avez de quoi substancier vos propos, il serait de bon ton de soumettre un rapport de bug.

Après plusieurs correspondances, je m'étais résolu à poster un rapport de bug (y'a environ 16 mois de cela), resté sans réponse...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

J'ai jamais réussi à obtenir de GCC ni de ICC, ni de VC, une vitesse aprochant ICL. Maintenant je préfererais me tromper, car si quelqu'un pouvais me prouver le contraire, ça m'arrangerait.
Un exemple (sur une FFT) est décrit dans le rapport de bug.

[t.b.p.]

Après plusieurs correspondances, je m'étais résolu à poster un rapport de bug (y'a environ 16 mois de cela), resté sans réponse...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

Et vous n'obtiendrez jamais aucune réponse à moins que de fournir un source pré-processé, c.a.d. compilable par lui même.

Les dev. de gcc peuvent être pénibles, mais si il y a une chose qu'ils ne peuvent refuser c'est un os à ronger

J'ai jamais réussi à obtenir de GCC ni de ICC, ni de VC, une vitesse aprochant ICL. Maintenant je préfererais me tromper, car si quelqu'un pouvais me prouver le contraire, ça m'arrangerait.
Un exemple (sur une FFT) est décrit dans le rapport de bug.

La série 4.x donne de bien meilleur résultat en C++ et pour ce qui du 'floating point intensive'; c'est flagrant lors de l'usage de SSE, en génération automatique - scalaires - ou vectoriel - via intrinsics.

J'ai un raytracer cohérent temps-réel, avec notament un chemin tout en SSE vectorisé. Que celà soit pour la construction du kd-tree (SAH) ou le rendu, en vectoriel ou scalaire, le binaire produit par gcc 4.2 est au moins aussi rapide que celui produit par ICC 9.1. En 32bit comme en 64bit. Msvc8 est à la ramasse d'au moins 25%.
Comme je l'ai dis précedement celà demande une certaine, disons, attention.
D'un autre coté il est beaucoup plus facile d'éduquer gcc que les 2 autres compilateurs.

PS: icc & icl à version égale produisent la meme chose, modulo le fait que dans un cas msvc est émulé (bug inclus) et gcc dans l'autre et que les bibliotheques attenantes different du fait de l'environement. J'insiste sur ce dernier point.

[Charlemagne]

Et vous n'obtiendrez jamais aucune réponse à moins que de fournir un source pré-processé, c.a.d. compilable par lui même.

Tant pis. GCC restera lent.

La série 4.x donne de bien meilleur résultat en C++ et pour ce qui du 'floating point intensive'; c'est flagrant lors de l'usage de SSE, en génération automatique - scalaires - ou vectoriel - via intrinsics.

Encore jamais essayé de version 4.
Elle n'existait pas quand j'ai posté mon rapport. Et puis les rares fois que j'utilise GCC, c'est plutôt sous Cygwin car je ne connais pas bien Linux et je n'ai pas facilement accès à des machines sous Linux. La version 4 ne semble malheureusement pas disponible sous Cygwin...

Je ne crois pas à la génération automatique d'instructions SSE (certes j'ai jamais essayé), ça ne vaudra jamais les intrinsiques.

Tu peux s'il te plaît essayer de compiler mon petit exemple sous GCC 4.X pour que je puisse comparer avec ICL.

PS:

le binaire produit par gcc 4.2 est au moins aussi rapide que celui produit par ICC 9.1. En 32bit comme en 64bit. Msvc8 est à la ramasse d'au moins 25%.

J'ai été fortement décu par ICL 9. Je sais pas ce qu'Intel a changé, mais ça vaut pour moi franchement pas la version 8.1. Je teste pourtant de tant en tant les nouvelles versions.

[t.b.p.]

Encore jamais essayé de version 4.
Elle n'existait pas quand j'ai posté mon rapport. Et puis les rares fois que j'utilise GCC, c'est plutôt sous Cygwin car je ne connais pas bien Linux et je n'ai pas facilement accès à des machines sous Linux. La version 4 ne semble malheureusement pas disponible sous Cygwin...

Si, si. Elle existait. http://gcc.gnu.org/releases.html

La version fournie en standard par Cygwin est tjs une 3.4.x je crois. La 4.2.0 ne devrait plus tarder, et de toute façon il suffit d'attraper un snapshot, ftp://gcc.gnu.org/pub/gcc/snapshots/ , et de le recompiler, Cygwin étant une cible majeure et supportée.

Je ne crois pas à la génération automatique d'instructions SSE (certes j'ai jamais essayé), ça ne vaudra jamais les intrinsiques.

L'auto-vectorisation vaut ce qu'elle vaut, c'est à dire pas grand chose tant pour gcc qu'icc. Mais comme je l'ai dit, que celà soit avec du C++ pur sucre + géneration de SSE scalaire ou via les intrinsics, gcc produit du code au moins aussi bon qu'icc si ce n'est meilleur.
Bon, l'exemple date un peu, mais 5M rayons/s sur un cpu j'aurais tendance a dire que c'est honnête: http://ompf.org/ray/wip/pix/20060201-01.jpg

Donc...

Tant pis. GCC restera lent.

Chacun voit midi à sa porte. Mais il est tjs dangereux de se lancer dans des generalisations

Tu peux s'il te plaît essayer de compiler mon petit exemple sous GCC 4.X pour que je puisse comparer avec ICL.

Ton test-case est incomplet.

EDIT pour répondre à l'edit: v8.1, v9.1, 32bit, 64bit même combat de nos jours (meme si 2 ans en arriere gcc se faisait pulveriser en 32bit par icc 8.1... ce n'est plus le cas)

[Charlemagne]

J'attendrai donc la version 4.X sous Cygwin pour comparer avec ICL. Ca fait néanmoins plus d'un an que je l'attends, sans trop d'impatience toutefois.
J'ai pas trop envie de compiler moi-même GCC, j'ai jamais fais ça, et c'est surement compliqué quand on connait pas.

[t.b.p.]

J'ai pas trop envie de compiler moi-même GCC, j'ai jamais fais ça, et c'est surement compliqué quand on connait pas.

C'est surtout que ça contribue au réchauffement global. Sinon, il y a tjs ce mémo: http://ompf.org/forum/viewtopic.php?t=29