On y "apprend" (les comparatifs sont toujours a prendre avec des pincettes) que le compilateur d'Intel genere un code en moyenne 15% plus rapide que celui de Gcc.
Un comparatif intéressant, qui peut permettre de se fixer sur l'un ou l'autre des compilateurs suivant ses besoins. Le compilateur d'Intel génère du "meilleur" code que celui de gcc dans la plupart des cas (d'après mes tests perso), mais il reste une chose qu'il ne sait pas faire : Compiler un noyau Linux. Les sources de Linux contiennent en effet pas mal de directives Gcc, et empêchent la compilation par tout autre compilateur. Mais bon, d'ici à ce qu'Intel ou quelqu'un d'autre s'y mette ...
A noter aussi que Intel C++ est gratuit pour une utilisation non-commerciale, mais reste très loin d'etre libre.
Aller plus loin
- le bench (45 clics)
- Intel C++ Compiler 7.0 (26 clics)
- GNU Gcc 3.2.1 (8 clics)
# Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 10.
Cette phrase est dite dans le teste une seule fois pour SciMark 2.0. Il n'est jamais dit que gcc est globalement moins rapide de 15 %. D'ailleur dans d'autre test gcc est plus rapide.
> Le compilateur d'Intel génère du "meilleur" code que celui de gcc dans la plupart des cas (d'après mes tests perso)
Ce n'est pas ce que dit le bench. Le bench dit que dans certains domaines le compilateur Inter est meilleur mais pas "dans la plupart des cas".
Pour avancer çà il faut que tu sois plus précis. Moi j'ai plus confiance au bench qu'à tes tests perso. On peut assi discuter de cette notion "brumeuse" de "meilleur code".
> mais il reste une chose qu'il ne sait pas faire : Compiler un noyau Linux.
Et oui, le compilateur Intel n'a pas toute les fonctionnalités de gcc pour compiler un noyau (Et le bench dit clairement que le compilateur Intel n'a pas toutes les fonctionnalités de gcc).
Le bench est un bon bench. Honnète et tout.
Mais ne bench ne dit pas :
- que gcc est globalement 15% plus lent que le compilateur Intel. D'ailleur gcc est plus rapide pour le bench OOPack (sauf pour les complex), aussi rapide pour Stepanov, plus rapide pour MazeBench et effectivement plus lent d'en moyenne 15 % pour le test SciMark 2.0.
- que le compilateur est Intel est meilleur. La conclusion du test les renvoies dos à dos.
Bref, gcc est globalement un très bon compilateur (comme le prouve l'article du bench).
J'ai l'impression que le modérateur n'a pas lu le bench pour accepter le commentaire qui accompagne la news.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
- GCC est libre lui, et c'est une suite de compilateurs, pas un simple compilateur
- GCC est disponible sur beaucoup de plateformes, pas sur une seule
- GCC est pérenne, ICC on n'en sait rien vu que Intel nous dit que la GPL est nocive. cf https://linuxfr.org/2002/12/03/10522.html(...)
- GCC peut recompiler entièrement une distribution GNU/Linux (et ce sur toutes les plateformes supportées)
- les développeurs GCC sont très réactifs (je ne sais pas pour ICC vu que je ne l'utilise pas)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
meme si tu le compile en source la version 3.2.1 c globalement plus simple a installer/utiliser que ICC :) (j'ai jamais reussi a le faire tourner avec son putain de serveur de licence)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Benjamin . Évalué à 8.
Tes deux premiers arguments sont tellement importants techniquement que comparer gcc à icc n'a meme pas grand sens. D'ailleurs, tu as omis de dire que gcc peut cross-compiler (ce qui est différent du fait d'exister sur plusieurs plateforme).
En pratique, quand bien meme icc serait meilleur (ce qui me choquerait pas, il est fait par ceux qui font le cpu qu'il cible), le gain de vitesse ne saurait compenser les efforts humains d'adapter son code et de devoir utiliser plusieurs compilos suivant la plate-forme ciblée...
Rien à voir 1.
Vous saviez que Qt-Win nécessitait une licence MS ou Borland, meme si l'on s'en sert avec gcc (cygwin) ?
Rien à voir 2.
Même si je suis pratiquement sur de la réponse, y'a-t-il moyen de rendre gcc abi-compatible avec Microsoft Visual C++ 6.0 (Entreprise Edition), ou l'inverse. (enfin, je voudrais savoir si on pourrait lier des .o gcc avec des .o MSVC++6EE, sur plateforme MSWin)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Roard (site web personnel) . Évalué à 5.
Très réactif, peut être pour certaines choses, mais bon l'intégration des patchs d'Apple sur gcc pour mixer ObjectiveC et C++, on les attends depuis LONGTEMPS
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par DiZ . Évalué à 2.
TRES LONGTEMPS
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Gniarf . Évalué à -1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Paerro Trime . Évalué à 2.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Gniarf . Évalué à -1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Paerro Trime . Évalué à 2.
Cependant, à priori, cette fonctionnalité est toujours sur les rangs pour l'intégration dans gcc 3.3.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Paerro Trime . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Olivier Jeannet . Évalué à 1.
Encore incompatible ??
Et pourquoi cette fois-ci ? Il s'agit toujours du C++ je suppose ?
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 2.
Je croyais, à tord, que gcc 3.3 serait incompatible 3.2 et après quelques fouilles pour confirmer j'ai rien trouvé pour appuyer mes dire (sauf un mail qui indiquait qui fallait utiliser --thread=posix pour libstdc++).
Désolé pour cette propagation d'une fausse information.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 1.
Les raisons je les connais mais il doit y en avoir. C'est comme les très nombreux patchs pour Linux qui sont en attende de nombreux mois.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Anonyme . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par benja . Évalué à 2.
Est-ce que çà donne un nouveau language dérivé des deux ou c'est simplement la possibilité d'utiliser des objets objective-c dans du code c++ (ou inversement) ?
Je connais un peu objc et ce serait cool si tu pouvais nous donner un petit exemple d'application concret.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Paerro Trime . Évalué à 2.
Grosso modo tu peux mettre du code c++ au milieu de ton code objc (ou l'inverse mais a priori c'est encore plus rare).
La syntaxe de l'objc et du C++ étant suffisament disjointes (si on exclus le tronc commun du C évidemment) le résultat tombe sous le sens.
C'est pratique par exemple si tu veux réutiliser des classes C++ déjà écrites dans un programme objc sans te faire mal à la tête.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par DiZ . Évalué à 3.
A faire un truc super crade
et accessoirement a porter ca http://www.mozilla.org/projects/chimera/(...)
ObjC++ existe deja, mais seulement dans le gcc Apple, pas encore dans la branche officielle.
>Je connais un peu objc et ce serait cool si tu pouvais nous donner un petit exemple d'application concret.
GNUstep est surement le plus gros projet libre multiplateforme (et libre sur toute les plateformes)
Tu y trouveras des frameworks pour coder des outils (Foundation) des applications "desktop" (AppKit) pour les bases de données (gdl2) ou pour un vrai serveur d'application entierement libre (gsWeb)
Pour la partie visible (concrete) je te conseillerais de voir des applis comme Gorm qui est surement le meilleur RAD libre ( QT Designer etant surement le seul concurent )
sinon tu as les applis GNUstep (GNUMail, GWorkspace, TalkSoup, ToyViewer.......)
ou tu peux aussi regarder les applis libre MacOSX pas encore porté comme Nitro ( http://nitro.jabberstudio.org/(...) ) , CVL ....
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
[D'abord, c'est très orienté GNUstep hein... (normal, mis à part GNUstep, sous linux y'a pas gd monde qui utilise ObjC).]
Donc, principalement, ça apporte le fait de pouvoir utiliser sans se prendre la tête des librairies ou des bouts de code C++ dans des programmes Objective C.
Classiquement, on peut imaginer un projet dont le "backend" est fait en C++, pour raisons historiques par exemple, auquel on veut coller une interface graphique (GNUstep ou Cocoa sur Apple).
Bon. Ben du coup tu construit ta GUI super rapidement en utilisant ObjC, et tu la branche sur ton code C++, voila. Et hop tu bénéficie des avantages GNUstep en plus (services...).
Comme pas mal de librairies intéressantes ont été faites en C++ (OpenH323 ou Gecko par exemple), ça permettrait d'avoir plus facilement des portages vers GNUstep, ce qui est intéressant. Bon y'a certaines libs (Gecko!) qui bénéficieraient aussi largement d'une réécriture en ObjC, mais si en attendant on peut l'utiliser pour batir quand même des trucs, c'est toujours ça de boulot évité pour le moment. Voilou.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Moby-Dik . Évalué à 1.
Parce que bon, franchement, s'accrocher à ObjectiveC, je vois pas l'intérêt. Même si certains trouvent peut-être le langage meilleur que C++, je ne pense pas que le différentiel soit suffisamment important pour justifier de s'enfermer d'une telle façon. "Faciliter les portages vers GNUStep", c'est rigolo, mais c'est bien à cause de ce choix de langage qu'il y a des problèmes de portage. Faire porter la responsabilité aux développeurs de gcc qui-traînent-les-pieds-à-committer-le-patch, c'est pas très constructif.
Enfin, libre à vous de continuer dans ce qui me paraît une impasse. Déjà qu'il y a Gnome et KDE en face de vous, si en plus vous imposez l'utilisation d'un langage exotique...
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par bleh . Évalué à 5.
Parce que ça prends enormement de temps et que faire des wrappers un peu dans le style gtk-- est particulièrement inefficace et est une perte de temps incroyable. Je ne sais pas si tu as une idée de la taille de l'API de GNUStep mais c'est assez enorme :
http://www.gnustep.org/resources/documentation/base/Base.html(...)
http://www.gnustep.org/resources/documentation/gui/Gui.html(...)
Avec AppKit, on est franchement surpris d'arriver à faire une interface cohérente en aussi peu de temps et avec un peu d'habitude, on apprécie franchement l'Objective-C.
Faire porter la responsabilité aux développeurs de gcc qui-traînent-les-pieds-à-committer-le-patch, c'est pas très constructif.
Parce qu'entre appliquer un patch et reécrire GNUStep en C++ tu trouves que le deuxième est plus constructif ?
Tu as l'air de penser que GNUStep est particulièrement fermé à cause de l'Objective-C alors qu'il n'en est rien. JIGS et RIGS apportent justement cette ouverture en permettant aux programmeurs java et ruby d'utiliser les bibliothèques GNUStep. L'ouverture serait encore plus grande si ce patch était appliqué, on verrait apparaitre peut-être plus de C++ et ça faciliterait grandement les portages. Alors dans ce cas moi je trouve que se plaindre d'un patch un peu "lent" à venir est constructif.
Déjà qu'il y a Gnome et KDE en face de vous, si en plus vous imposez l'utilisation d'un langage exotique...
Bof. Je n'ai pas l'impression que GNUStep, Gnome et KDE jouent dans la même catégorie. GNUStep part d'une base totalement différente, et à mon avis, plus saine Openstep. Et pour en revenir au langage exotique, j'ai constaté que le projet était particulièrement vivant en dépit du langage et, moi même, je prends beaucoup de plaisir à programmer en Objective-C (ça ne fait que 6 mois mais je suis surpris de l'avancement de l'appli que j'essaye de faire, je signale quand même que je programme pas mal en C++ et en java en dehors de mon temps libre, ceci explique peut-être que je n'ai pas eu trop de mal à apprendre l'Objective-C). Alors laissons lui une chance ;-)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à -1.
> Parce qu'entre appliquer un patch et reécrire GNUStep en C++ tu trouves que le deuxième est plus constructif ?
C'est plus constructif pour qui ?
Pour un petit nombre de développeur.
Gcc maintient déjà Ojective C qui n'est pas très utilisé. Tu leur demandes de maintenir une fonctionnalité supplémentaire car c'est plus confortable pour un petit nombre. Les ressources du team gcc ne sont pas extensible à l'infini. De plus ce patch peut être une contrainte pour les ajouts de fonctionnalité plus populaire.
Puis le travail de maintient de cette fonctionnalité doit être fait par rapport a tout les autres ajout. Que ce soit gcc ou Apple ou Gnustep qui maintient cette fonctionnalité n'est pas très différent.
Si gcc applique ce patch, c'est bon pour la diffusion de cette fonctionnalité. Mais si cette fonctionnalité est peu utilisé...
Par contre je comprend que l'utilisateur final n'aprécie que moyennement d'appliquer un patch.
C'est un avis que je donne bien que je ne connais pas tout les tenants et aboutissants du problème. C'était pour dire qu'il n'est pas forcement plus constructif/intéligent au team gcc d'appliquer ce patch.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Ben, oui, mais d'un autre côté c'est quand même le langage par défaut sous Mac maintenant... ça apporte un certain nombre de devs je pense, non ?
sur le reste je suis d'accord, l'inclusion d'un patch peut poser des problèmes. Mais bon, à l'extrème on ne touche plus à rien alors.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Paerro Trime . Évalué à 2.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Moby-Dik . Évalué à 2.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par bleh . Évalué à 2.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Herve Lebrie . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Au niveau "logique", c'est de la programmation objet, donc un programmeur C++ prendra vite le coup. Un programmeur C sans connaissances de la POO, ben, il faudra qu'il apprenne un minimum ce que c'est de toute façon.
La façon de concevoir une appli peut différer avec C++ grâce au côté dynamique du langage, de la disponibilité des objets distribués, de l'ensemble du framework... Un programme graphique se programmera d'une façon différente (plus rapide), car utilisant le framework GNUstep, et surtout, Gorm. Comportements indéfinis... disons que ObjC est plus simple que C++, donc plus aisément maitrisable. Le plus simple est d'aller jeter un oeil sur les tutoriaux sur http://www.gnustep.it(...) ou d'aller poser des questions sur #gnustep (irc.debian.org)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Herve Lebrie . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
Ben honnêtement, si c'était faisable, pourquoi pas... le problème c'est que ObjC a bien un intérêt, c'est d'être dynamique à l'exécution. Ce que C++ n'est pas. Alors, oui, on peut imaginer un éventuel portage vers C++, qui "émulerait" toute cette partie dynamique (c'est un peu ce qui a été fait chez mozilla avec Gecko en fait!), le problème c'est qu'on aurait un truc en C++ pas franchement agréable à écrire et à maintenir.
Le truc c'est que GNUstep n'utilise pas ObjC parce que ça fait bien, ou pour être original, mais parce que le langage a des avantages par rapport à d'autres.
Maintenant, à chaque problème le bon outil, est ObjC est excellent pour tout ce qui est GUI, mais pour un backend, C++ peut être éventuellement un meilleur choix (profitons des templates par exemple); c'est à voir.
Bon et puis si vraiment ObjC te sort par les trous de nez, tu peux coder en java, guile, rubby, etc.
Enfin, libre à vous de continuer dans ce qui me paraît une impasse. Déjà qu'il y a Gnome et KDE en face de vous, si en plus vous imposez l'utilisation d'un langage exotique...
Bah chacun son point de vue hein :)
Moi je ne pense pas qu'on ait "Gnome et KDE contre nous", d'une part parce qu'on a pas les mêmes objectifs (multiplateforme), et deuxièmement parce que la "philosophie" derrière est différente. On préfère s'inspirer de NeXT/OPENSTEP que de windows/mac : on essaie de faire des applis petites, qui font bien UNE chose, ergonomiques, avec l'ensemble des logiciels communiquant entre eux pour faire des choses plus complexes.
D'un point de vue personnel, je m'en fous si on devient pas le desktop #1 sous unix, ce qui m'intéresse moi c'est d'utiliser un truc qui me convient. De toute façon, ce qu'on veut faire ne conviendra pas forcément à tout le monde, alors... (je suis admiratif du boulot qui a été fait sur KDE par ailleurs)
Et puis on aura effectivement pas les ressources pour refaire tout ce qui a été fait sur Gnome et KDE en 2 semaines hein :-P maintenant, j'ai aussi confiance dans le fait qu'on arrive à développer plus rapidement (grâce au framework et à Gorm) les applis, et que même sans être nombreux on arrive à faire avancer les choses tranquillement. On verra bien, mais je pense que ça vaut le coup de tenter.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Tutur . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Vivi (site web personnel) . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par RB . Évalué à 3.
Ce qui serait intéressant pour moi serait de compiler de grosses applications style OO, moz ou KDE et de comparer leurs vitesses. Il faudrait peut être aussi tester les différences induites par les différentes options de gcc, mais il y en a tellement...
Sauf erreur je crois que le noyau linux avait été compilé avec intel c++ 6.0.
Pour le reste, gcc est quand même excellent quand on voit les performances atteintes et le fait qu'il compile pour une multitude d'architectures.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par grafit . Évalué à -1.
> Cette phrase est dite dans le teste une seule fois pour SciMark 2.0. Il n'est jamais dit que gcc est globalement moins rapide de 15 %. D'ailleur dans d'autre test gcc est plus rapide.
Cette phrase ne parle pas de la vitesse de gcc, mais de celle du code généré
nuance...
> J'ai l'impression que le modérateur n'a pas lu le bench pour accepter le commentaire qui accompagne la news
J'ai l'impression que tu n'as pas lu la news qui accompagne le bench ;-)
(-1)
# Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par DPhil (site web personnel) . Évalué à 10.
Je pense qu'ICL est surtout performant sur les nouvelles architecture (pentium IV), mais je ne peut pas faire le test.
Il est à noter qu'un soft compilé avec ICL des optimisations pentium IV est plus lent sur un Athlon qu'une version compilée sans optimisation. Des tests ont été effectuées avec OggEnc (il y a des lien sur le forum audio-illumination.org)
# Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Troy McClure (site web personnel) . Évalué à 10.
[Dans la suite je fais un blocage sur les perf du bench LU, qui est représentatif de la puissance du processeur et de la capacité du compilo à bien optimiser des petites boucles assez simples de calcul en virgule flottante -- je n'ai pas regardé les autres résultats]
Du coup j'ai essaye sur mon celeron-450 (un bon vieux celeron avec juste le mmx)
Composite Score: 70.06
FFT Mflops: 65.28 (N=1024)
SOR Mflops: 108.50 (100 x 100)
MonteCarlo: Mflops: 17.16
Sparse matmult Mflops: 52.35 (N=1000, nz=5000)
LU Mflops: 107.00 (M=100, N=100)
(gcc-3.2.1 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math)
(on notera que j'ai viré l'option -mcpu)
ah ben c'est con, les perfs sont les mêmes que sur le pIII du gars! peut-être que le test ne tire pas partie du SSE puisque si je ne m'abuse celui-ci travaille en simple précision et le bench est en double-prec. Passons.
Pour continue à voir, je vais sur un celeron-600 (qui doit avoir le SSE, enfin j'en sais trop rien)
rebelote:
Composite Score: 82.21
FFT Mflops: 94.39 (N=1024)
SOR Mflops: 101.21 (100 x 100)
MonteCarlo: Mflops: 35.32
Sparse matmult Mflops: 44.16 (N=1000, nz=5000)
LU Mflops: 135.99 (M=100, N=100)
(gcc-3.2.1 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=pentium2)
Flute alors, son bi-pIII est vraiment pas fougueux, un céléron-600 est 33% plus véloce... on va mettre ça sur le compte du SMP :-/
Sur la machine en question, il y a aussi icc-6.0 alors autant faire la comparaison:
Composite Score: 122.48
FFT Mflops: 88.27 (N=1024)
SOR Mflops: 157.43 (100 x 100)
MonteCarlo: Mflops: 89.48
Sparse matmult Mflops: 72.82 (N=1000, nz=5000)
LU Mflops: 204.39 (M=100, N=100)
(icc -O3 -ipo -axK)
Mazette ! sur ce coup, icc est 60% plus performant que gcc ! Bon, on va dire que c'est parce que c'est du intel, allons voir sur un athlon.
La machine en question est un athlon-XP 1400, une machine bas de gamme d'assembleur.
Composite Score: 345.81
FFT Mflops: 320.63 (N=1024)
SOR Mflops: 324.40 (100 x 100)
MonteCarlo: Mflops: 112.32
Sparse matmult Mflops: 327.68 (N=1000, nz=5000)
LU Mflops: 644.03 (M=100, N=100)
(gcc-3.2.1 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=pentium2)
Composite Score: 436.18
FFT Mflops: 339.35 (N=1024)
SOR Mflops: 448.13 (100 x 100)
MonteCarlo: Mflops: 267.10
Sparse matmult Mflops: 409.60 (N=1000, nz=5000)
LU Mflops: 716.71 (M=100, N=100)
(icc -O3 -ipo -axK)
Alors là je suis plus qu'impressionné! Les perf sont vraiment bluffantes à croire qu'il y a un bug dans le bench. La bonne nouvelle c'est que gcc n'est pas tellement à la rue. Par contre j'ai pas de p4 sous la main pour faire la comparaison..
A titre d'info j'ai aussi lancé le bench sur une Bi-Alpha (21264A à 667MHz). A côté de l'athlon elle fait plutot pâle figure (là aussi je suis plus que surpris)
Composite Score: 194.86
FFT Mflops: 214.46 (N=1024)
SOR Mflops: 236.93 (100 x 100)
MonteCarlo: Mflops: 48.22
Sparse matmult Mflops: 175.55 (N=1000, nz=5000)
LU Mflops: 312.68 (M=100, N=100)
(cc -O3 -arch ev67 -fast)
A sa décharge, il faut dire que la machine est assez chargée (load = 2.7) et que le test n'évalue que la puissance brute du processeur, il ne tire pas partie du cache assez gros de cette machine.
Par contre on peut comparer le compilateur compaq avec gcc (3.2):
Composite Score: 155.17
FFT Mflops: 199.73 (N=1024)
SOR Mflops: 167.08 (100 x 100)
MonteCarlo: Mflops: 50.65
Sparse matmult Mflops: 220.92 (N=1000, nz=5000)
LU Mflops: 137.46 (M=100, N=100)
(gcc -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -mcpu=ev67 -mtune=ev67)
... mouaif vraiment pas convainquant, sur le LU le compilo compaq a été plus de 2 fois plus performant que gcc.. je n'ai peut-être pas utilisé les bonnes options pour gcc :-/ (en particulier pour les histoires d'aliasing mais j'ai la flemme de chercher)
Allez, un dernier coup sur une Origin 2000 pas très fraiche (à base r12k à 400MHz):
Composite Score: 148.34
FFT Mflops: 129.78 (N=1024)
SOR Mflops: 242.08 (100 x 100)
MonteCarlo: Mflops: 64.22
Sparse matmult Mflops: 108.86 (N=1000, nz=5000)
LU Mflops: 196.73 (M=100, N=100)
(cc -Ofast -OPT:alias=restrict:roundoff=3)
et avec gcc (3.0.4):
Composite Score: 114.10
FFT Mflops: 124.23 (N=1024)
SOR Mflops: 155.90 (100 x 100)
MonteCarlo: Mflops: 20.97
Sparse matmult Mflops: 102.08 (N=1000, nz=5000)
LU Mflops: 167.32 (M=100, N=100)
(gcc-3 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -mips3)
bon, gcc n'est pas trop ridicule sur ce coup il s'en sort bien :)
au final c'est bien dur de tirer des conclusions .. mis à part que je ne comprends comment l'auteur du bench a obtenu des performances bien plus mauvaise que celles que j'ai sur un celeron-600.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Anonyme . Évalué à 4.
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 261.73
FFT Mflops: 194.67 (N=1024)
SOR Mflops: 248.32 (100 x 100)
MonteCarlo: Mflops: 24.67
Sparse matmult Mflops: 373.42 (N=1000, nz=5000)
LU Mflops: 467.58 (M=100, N=100)
moa@dionysos:~/tmprm$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Pentium(R) 4 CPU 1.70GHz
stepping : 2
cpu MHz : 1700.122
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3381.65
moa@dionysos:~/tmprm$ gcc --version
2.95.4
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Troy McClure (site web personnel) . Évalué à 1.
parce que si c'est le cas, ça veut quand même dire que pour du calcul brut, le couple gcc+athlon est très nettement plus performant que gcc+p4, à fréquences égale (je m'étais gourré plus haut, c'est pas un athlon xp 1400 mais un 1600, qui tourne à 1400MHz)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Anonyme . Évalué à 2.
là ça donne
moa@dionysos:~/tmprm$ ./scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 259.40
FFT Mflops: 195.54 (N=1024)
SOR Mflops: 245.16 (100 x 100)
MonteCarlo: Mflops: 24.76
Sparse matmult Mflops: 367.15 (N=1000, nz=5000)
LU Mflops: 464.40 (M=100, N=100)
Plus ou moins la meme chose
J'ai refait avec
moa@dionysos:~/tmprm$ gcc-3.2 --version
gcc-3.2 (GCC) 3.2.1 20020924 (Debian prerelease)
Copyright © 2002 Free Software Foundation, Inc.
Ce logiciel est libre; voir les sources pour les conditions de copie. Il n'y a PAS
GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER.
moa@dionysos:~/tmprm$ scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 260.95
FFT Mflops: 193.80 (N=1024)
SOR Mflops: 249.61 (100 x 100)
MonteCarlo: Mflops: 24.40
Sparse matmult Mflops: 366.12 (N=1000, nz=5000)
LU Mflops: 470.80 (M=100, N=100)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Anonyme . Évalué à 1. Dernière modification le 05 décembre 2021 à 17:55.
autre P4
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Anonyme . Évalué à 1.
Ce test taperait dans un domaine ou les intels sont plus faibles ? Ou bien ce test ferait des mesures biaisées ?
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Moby-Dik . Évalué à 1.
$ ./scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 413.15
FFT Mflops: 367.98 (N=1024)
SOR Mflops: 386.94 (100 x 100)
MonteCarlo: Mflops: 131.59
Sparse matmult Mflops: 412.18 (N=1000, nz=5000)
LU Mflops: 767.04 (M=100, N=100)
(gcc -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=athlon -o scimark2 *.c
gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk))
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par dinomasque . Évalué à 1.
[aurel@Macross SCI]$ ./scimark2
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 267.35
FFT Mflops: 249.89 (N=1024)
SOR Mflops: 291.96 (100 x 100)
MonteCarlo: Mflops: 58.10
Sparse matmult Mflops: 353.29 (N=1000, nz=5000)
LU Mflops: 383.52 (M=100, N=100)
[aurel@Macross SCI]$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 7
model name : AMD Duron(tm) Processor
stepping : 1
cpu MHz : 1200.073
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 2392.06
BeOS le faisait il y a 20 ans !
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Troy McClure (site web personnel) . Évalué à 2.
Il faudrait voir aussi si icc peut apporter un gain significatif sur des pentiums 4.. c'est ptet le cas, c'est ptet du flan.
De toute manière c'est un bench qui reste très spécialisé (donc biaisé si on cherche à l'interpreter comme une mesure globale des perfs des processeurs) , la plupart des pc ne passent pas leur temps à factoriser des matrices, et il est certain qu'on peut trouver des implementation plus efficaces. Mais ça reste interessant de voir les performances qu'on peut obtenir sur un code simple en fonction du couple (gcc + processeur) . Il serait sans doute interessant de confronter ça à un bench similaire mais utilisant des procedures ultra-optimisées pour chaque processeur (intel founit ses propres versions des BLAS/lapack, qui font entre autre les factorisations LU, malheureusement elles sont payantes)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
L'athlon dispose de 3 décodeur et cette instruction est executé "à coût nul". Le P4 ne dispose que d'un seul décodeur et perd donc un coup de clock en comparaison de l'Athlon (la vitesse n'est pas divisé par 2 grace au trace cache (program cache situé après le décodeur) qui doit faire son boulot ensuite).
Icc utilise un vrai scheduler pour pile d'où les différences de perf. Maintenant essayer gcc avec les options -msse pour utiliser ( et/ou -msse2 pour le P4 ?) les instructions SSE en scalair qui utilise des registres ou gcc sera plus à l'aise. (Utiliser aussi le nouveau allocateur de registre option -fra ou un truc du genre) -mx87,sse existe en version expérimental, cela utilise les 2 styles d'instructions. Cela devrait donner le code le plus rapide.
-ffast-math n'est pas recommandé en bench, cela peut changer le comportement du programme.
"La première sécurité est la liberté"
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Anonyme . Évalué à 1.
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 304.09
FFT Mflops: 126.76 (N=1024)
SOR Mflops: 305.87 (100 x 100)
MonteCarlo: Mflops: 52.63
Sparse matmult Mflops: 461.52 (N=1000, nz=5000)
LU Mflops: 573.67 (M=100, N=100)
[^] # reprennons à 0
Posté par Anonyme . Évalué à 3. Dernière modification le 05 décembre 2021 à 17:57.
Bon autant pour moi, j'avais pas fait recompiler les autres .o avec les bonnes options
Maintenant, avec les options données par Coin.
Sur le P4 1.7
Donc, avec gcc 2.94.5
Avec gcc-3.2
Sur le P4 2Gh
et avec gcc 3.0
sur un biproc GenuineIntel Pentium III (Coppermine) 796.553
avec gcc 2.95.4
et avec gcc 3.0
finalement, sur un PII (Deschutes) 350 avec gcc 3.2
(en fait gcc-3.2-base 1:3.2.1-0pre3)
Beuh…
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par wismerhill . Évalué à 2.
Using 2.00 seconds min time per kenel.
Composite Score: 423.64
FFT Mflops: 366.44 (N=1024)
SOR Mflops: 417.09 (100 x 100)
MonteCarlo: Mflops: 60.19
Sparse matmult Mflops: 451.97 (N=1000, nz=5000)
LU Mflops: 822.49 (M=100, N=100)
À noter que si je compile avec les options par défaut (c'est à dire juste -O6) ça donne ça
Using 2.00 seconds min time per kenel.
Composite Score: 435.46
FFT Mflops: 363.38 (N=1024)
SOR Mflops: 417.09 (100 x 100)
MonteCarlo: Mflops: 58.87
Sparse matmult Mflops: 587.77 (N=1000, nz=5000)
LU Mflops: 750.18 (M=100, N=100)
Donc une différence assez notable sur certains tests.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par wismerhill . Évalué à 2.
Bon, bien sur il s'agit de tests de base qui ne profitent probablement pas de certaines fonctionnalités avancées de ces cpu, mais ça indique que le design de l'athlon est en lui-même plus performant que celui du P4.
D'ailleur si je me souviens bien, le P4 a été "simplifié" pour favoriser la montée en fréquence. il me semble que des bench à fréquence égale donnaient toujours le P3 bien au-dessus du P4.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Benjamin . Évalué à 4.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Moby-Dik . Évalué à 2.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Machine de test :
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 11
model name : Intel(R) Celeron(TM) CPU 1200MHz
stepping : 1
cpu MHz : 1211.945
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 2418.27
$ cat /etc/mandrake-release
Mandrake Linux release 9.0 (dolphin) for i586
$ gcc --version
gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-1mdk)
$ bc++
Borland C++ 5.7 Open Edition Copyright (c) 1987, 2002 Borland
(Kylix3 OpenEdition US)
Avec gcc et optimisation pour Pentium2 :
CFLAGS = -O3 -funroll-all-loops -fomit-frame-pointer --fast-math -march=pentium2
Composite Score: 277.95
FFT Mflops: 207.65 (N=1024)
SOR Mflops: 367.74 (100 x 100)
MonteCarlo: Mflops: 78.95
Sparse matmult Mflops: 316.60 (N=1000, nz=5000)
LU Mflops: 418.81 (M=100, N=100)
Avec gcc et optimisation pour Pentium3 :
CFLAGS = -O3 -funroll-all-loops -fomit-frame-pointer --fast-math -march=pentium3
Composite Score: 277.61
FFT Mflops: 208.64 (N=1024)
SOR Mflops: 366.34 (100 x 100)
MonteCarlo: Mflops: 79.18
Sparse matmult Mflops: 315.08 (N=1000, nz=5000)
LU Mflops: 418.81 (M=100, N=100)
Avec le compilateur BCC de Borland (PentiumPro + Fast floating point) :
CFLAGS = -6 -O2 -ff
Composite Score: 200484266.47
FFT Mflops: 61416923.94 (N=1024)
SOR Mflops: 376358400.00 (100 x 100)
MonteCarlo: Mflops: 41553476.16
Sparse matmult Mflops: 180043956.04 (N=1000, nz=5000)
LU Mflops: 343048576.21 (M=100, N=100)
Remarque : Les chiffres sont nettement plus trop gros pour le compilateur de Borland... Je n'ai pas le temps de regarder de où ça vient... Si quelqu'un à une idée... Moi je pense que ça vient simplement de la conversion flops vers Mflops qui n'est pas réalisée ! (car le temps d'exécution est comparable à celui de gcc...)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
[^] # Les options, ça change tout :
Posté par Ptah . Évalué à 2.
D'abord avec CFLAGS = -O6:
Using 2.00 seconds min time per kenel.
Composite Score: 339.07
FFT Mflops: 193.80 (N=1024)
SOR Mflops: 335.71 (100 x 100)
MonteCarlo: Mflops: 31.51
Sparse matmult Mflops: 508.03 (N=1000, nz=5000)
LU Mflops: 626.30 (M=100, N=100)
Ensuite avec CFLAGS = -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math
Using 2.00 seconds min time per kenel.
Composite Score: 421.51
FFT Mflops: 270.84 (N=1024)
SOR Mflops: 331.09 (100 x 100)
MonteCarlo: Mflops: 56.63
Sparse matmult Mflops: 550.72 (N=1000, nz=5000)
LU Mflops: 898.25 (M=100, N=100)
Il y a un sacré gain de performance ; les options donnent des écarts > 25% pour le même compilo !! De là à trouver les 15% annoncés entre gcc et ic++ significatives, j'ai comme un doute sur la méthodologie ..
Ma machine : cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.26GHz
stepping : 4
cpu MHz : 2254.026
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 4495.76
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
À tout hasard j'ai aussi essayé avec gcc 3.2.1 et les options -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math ; curieusement ça le fait moins pour les 2 derniers tests ;
il doit y avoir de nouvelles options qui vont bien .. quelqu'un me les donne ?
Using 2.00 seconds min time per kenel.
Composite Score: 422.33
FFT Mflops: 261.11 (N=1024)
SOR Mflops: 320.09 (100 x 100)
MonteCarlo: Mflops: 59.92
Sparse matmult Mflops: 650.48 (N=1000, nz=5000)
LU Mflops: 820.02 (M=100, N=100)
[^] # Re: Les options, ça change tout :
Posté par Tom Sheldon . Évalué à 1.
la différence sur mon pentium 4m est flagrante, voila les résultats :
cc -O3 -march="pentium4" -pipe -funroll-all-loops -fomit-frame-pointer -ffast-math :
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 345.87
FFT Mflops: 200.95 (N=1024)
SOR Mflops: 243.92 (100 x 100)
MonteCarlo: Mflops: 80.61
Sparse matmult Mflops: 516.03 (N=1000, nz=5000)
LU Mflops: 687.83 (M=100, N=100)
et avec
cc -O3 -march="pentium4" -funroll-all-loops -fomit-frame-pointer -ffast-math -mfpmath=sse :
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark(...) **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 366.41
FFT Mflops: 219.13 (N=1024)
SOR Mflops: 268.38 (100 x 100)
MonteCarlo: Mflops: 70.09
Sparse matmult Mflops: 522.20 (N=1000, nz=5000)
LU Mflops: 752.25 (M=100, N=100)
cat /proc/cpuinfo :
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz
stepping : 4
cpu MHz : 1798.831
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 3555.32
# Page de bench multi lanagage
Posté par Cédric Foll . Évalué à 2.
Lecture plus que recommandée.
http://www.bagley.org/~doug/shootout/(...)
# Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Bouiaw . Évalué à 2.
Mais comment se fait il que icc 7.0 soit moins performant sur quasiemment tout les tests que icc 6.0 ???
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Bouiaw . Évalué à 1.
# +15% - quel intérêt ?
Posté par core . Évalué à -1.
A coté, GCC a l'avantage : 1) d'être *plusieurs* compilateurs 2) d'être fortement multi-architectures, ce qui me semble être un avantage énorme (je dirais même que ce point a tendance à déjustifier l'existence même des Java, .Net et autre Mono...) 3) d'être libre et donc facilement améliorable, bug-fixable etc.
[^] # Re: +15% - quel intérêt ?
Posté par wismerhill . Évalué à 3.
Je crois que t'a pas bien compris l'intérêt de java et autre .net.
Le principe c'est de ne compiler qu'une fois et d'exécuter partout (une espèce de cas intermédiaire entre un script et un code vraiment compilé).
C'est vrai que tu as gcc à peu près partout, mais il te faut le code source et recompiler pour chaque architecture.
Ne comprend pas ma remarque de travers, je ne suis pas très partisan de java et je trouve préférable d'avoir un programme vraiment compilé pour son processeur. Je faisait juste remarquer que ta comparaison ne tient pas.
[^] # Re: +15% - quel intérêt ?
Posté par RB . Évalué à 1.
Il faut dire que quand Java a débuté, il n'y avait pas vraiment de compilateurs multi-platteformes et on se disait qu'il serait plus simple de ne compiler qu'une seule fois et de faire des machines virtuelles sur les différentes architectures. Actuellement, les bonnes machines virtuelles ne touchent qu'une partie des platteformes et l'exécution est nettement plus lente qu'en natif. D'un nautre côté on a gcc qui compile pour toutes les architectures et si on l'associe à des libs additionnelles comme qt, il devient possible de compiler pour tout un tas de platteformes, bien plus que celles possédant un jre fonctionnel et avec un gain de vitesse à l'exécution.
Bref à mon avis Java est sur le déclin, peut-être que gcj lui donnera un coup de pouce ?
[^] # Re: +15% - quel intérêt ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Et c'est pour ça que le gentil lapin de paques a fait la première jvm avec l'aide du père noël, tralalilala.
[^] # Re: +15% - quel intérêt ?
Posté par matiasf . Évalué à 3.
Il est 15% plus lent pour un test (voir le premier commentaire ou lire le bench) et est plus rapide dans d'autres.
Même si gcc était 15 % plus lent, le fait que ce soit un free software sera mon préféré.
Messieurs montrez que vous êtes plus attentif à la license d'un compilateur, la disponibilité du code, qu'à son code généré ! Sinon c'est que vous n'aimez pas vraiment la philosophie du free software.
# Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par kesako . Évalué à 2.
Quelqu'un a des liens sur le sujet ?
Exemple type : apache 1.3 est il meilleur sur sparc compilé avec gcc ou avec CC ?
Merci d'avance
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas LAURENT . Évalué à 1.
Par contre je n'ai pas d'élément de comparaison avec gcc...
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par kesako . Évalué à 1.
Duquel tu parles ?
# Prix compilo Inter C++
Posté par matiasf . Évalué à 2.
Le profiler : 700
gcc + gprof : 0
Vu le prix, la non disponibilité des sources, des gains uniquement dans des domaines bien précis, ces moindre fonctionnalité face à gcc, le chois de ICC doit être bien justifié et ne conserne que quelques niches.
[^] # Re: Prix compilo Inter C++
Posté par lucio . Évalué à 1.
le prix est effectivement un élément du dossier pour faire un choix de compilateur sous Linux.
Pour une entreprise (et je pense que c'est un public pro que vise Intel avec son compilateur), il y a d'autres éléments à ne pas négliger:
1. Le respect de la norme (C, C++): c'est un dossier fondamental pour bien des clients,
2. La possibilité d'avoir accès à un support (c'est évidement payant) sur le produit choisi: je suppose que certaines sociétés doivent proposer ce genre de service pour gcc, quelqu'un a-t-il une expérience dans ce domaine ?
3. Les debuggers qui "vont avec". Pour gcc, il y a gdb et les front-end qui marchent avec (ddd), qu'en est-il pour icc (qui dit être OK pour l'usage de gdb mais fournit un debuger nommé idb)
[^] # Re: Prix compilo Inter C++
Posté par Olivier Jeannet . Évalué à 1.
Pour gcc, c'est Cygnus qui assure le support, c'est d'ailleurs une des premières et une des rares sociétés commerciales qui a réussi dans le secteur du support de logiciel libres. Cygnus a été racheté par RedHat il y a un an ou deux.
# OpenMP
Posté par Xmanu . Évalué à 3.
[^] # Re: OpenMP
Posté par Troy McClure (site web personnel) . Évalué à 3.
J'avais essayé odinmp il y a un bout de temps et ce n'était pas concluant du tout (force tendance au crash). Je ne pense pas qu'il y ait d'histoire de royalties, les specifications sont librement disponibles http://www.openmp.org/specs/index.cgi(...) . La principale raison pour l'absence d'openmp doit être que finalement il y a très peu de demande là dessus (ce que je comprends)
[^] # Re: OpenMP
Posté par Jean-Yves B. . Évalué à 2.
Sinon, Omni fonctionne bien comme compilo OpenMP. Il a le défaut d'être en Java mais sinon il fonctionne bien. En plus il est facile de plugger l'environnement d'exécution que l'on veut dessus (si le backend pthread ne te plait pas).
# Intéret d'Intel ?
Posté par Gaël Le Mignot . Évalué à 4.
Donc, je me demande vraiment où Intel est gagnant: le développement d'un compilateur complet doit leur coûter plus cher, alors qu'avoir un gcc plus performant sur les processeurs Intel pourrait convaincre certains d'acheter de l'Intel. Je ne pense pas que le prix des quelques licences venudes soit suffisant pour justifier ça de la part d'un fabriquant de matériel.
Si quelqu'un a un début d'explication, je suis preneur.
[^] # Re: Intéret d'Intel ?
Posté par matiasf . Évalué à 2.
1- Le pognon. Gcc il ne peuvent pas gagné d'argent car RedHat (l'ex équipe cygnus) est trop bien placé pour le support et Intel ne peut vendre de version "spécialisé" de gcc. Leur version sera obligatoirement sous GPL.
2- peut-être garder quelques informations secrètes.
NB : le compilo icc coute 300 et il faut ajouter 400 pour avoir un profiler !
[^] # Re: Intéret d'Intel ?
Posté par Patrice Fortier . Évalué à 2.
Intel fait des procs, et il faut bien tester leurs performances.
Qui de mieux que Intel pour faire un compilo totalement adapté a cette tache.
gcc integre peu d'optimisations spécifiques aux intel haut de gamme, et ses performances étaient jugées médiocres pour les versions 2.x. Lors de la sortie de icc 6, les benchs (on y revient toujours :)), montraient que icc enfoncait gcc ds a peu pres tous les domaines (jusqu'a ~40%, et ~25% pour VC++). Meme en mettant une marge de 10% sur ces chiffres, ca fait une bonne différence de perf...
Ce qui est amusant, c'est que, comme l'a noté qqn d'autre, icc 7 est plus lent que le 6...
D'autre part, comme le comparatif n'était pas fait par intel, ils ont testé aussi les athlon, et ces procs profitaient également des optimisations de icc 6.
Enfin, le code des compilos intel est truffé de licenses. Il ne peuvent simplement pas se permettre de le filer a des projets open-sources, et meme s'ils le faisaient, ces memes projets refuseraient ces contributions (car soumises a des licenses).
Il doit bien sur y avoir d'autres raisons, mais ca donne deja une bonne idée.
# Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Gniarf . Évalué à 5.
<troll>
quelle merde, ce gcc avec ses extensions propriétaires !
</troll>
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par wismerhill . Évalué à 1.
Je me demande pourquoi gcc introduit des extensions non-standards, le standard n'est-il pas suffisament fourni?
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Éric (site web personnel) . Évalué à 0.
Pour niquer l'interopérabilité et enfermer les gens dans leur soft. Contrairement à l'autre qui est interopérable et donc beaucoup moins mauvais pour l'utilisateur
Damned, les préjugés voudrait que on parle de intel et que "l'autre" soit gcc mais non, on parle bien de gcc.
</troll>
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Anonyme . Évalué à 1.
Pour ma part, je ferais abstraction de l'hypocrite usage de telles borrnes pour te répondre.
L'interopérabilité est une chose importante et il serait interessant de connaitre le point de vue de ceux qui implementer de telles limites.
Mais quoi qu'il en soit, du fait que ces logiciels soient libre, le problème est moindre puisque materiellement ce n'est pas une impasse. C'est juste génant.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Dawm . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Misc (site web personnel) . Évalué à 2.
j'avais ca :
------------
private :
static const struct lien {
int num_commande ;
//si je met un string ici, visual c++ et c++ builder
//me jette avec un message abscons.
//je vérifirai si cela est 'standard'
char* commande ;
}
m_Correspondance[];
------------
donc, sous gcc, c'etait pas un char*, mais un string.
et en mettant char*, les comparaisons marchaient encore.
mais c'est pas le standard.
et le projet était a rendre sous c++ builder, qui lui se contente de comparer les pointeurs... et gcc compare les chaines pointés, c'est completement differents.
y aussi des bugs dans c++ builder, et sous visual c++, qui empeche de compiler quand il y a une initialisation d'un membre constant statique :
static const int COIN = 42;
ben ca passe pas ( visual ) et c'est standard...
pour builder, c'est le contraire, je croit .
c'est a dire que c'est initialiser la constante a part qui marche pas...
je suis pas sur, j'ai pas de builder a porté de main.
pour reference, c'etait dans un article de frederic mazué, un test de c++ builder dans Programmez! que j'ai trouvé la premiere fois ca.
et maintenant dés que mon code compile pas, je sais que c'est un bug dans le compilo ;)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Moby-Dik . Évalué à 1.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Dawm . Évalué à 1.
field `main(...)::MaClasse::COIN' in local class cannot be static
Pour les niveaux de standards des compilateurs, je pense que GCC 3.2 reste le plus avancé en C++, bien qu'il parait que VC++ 7 a fait de gros progrés dans l'implémentation du standard (pas utilisé assez pour en témoigner). Ceci dit, difficile de faire pire que le 6 qui se plantait dés qu'il voyait marqué "template" quelque part.. Remarque, GCC 2.9 est pas top non plus dans ce domaine.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
et en mettant char*, les comparaisons marchaient encore.
mais c'est pas le standard.
et le projet était a rendre sous c++ builder, qui lui se contente de comparer les pointeurs... et gcc compare les chaines pointés, c'est completement differents.
Euh, un char* et un std::string ne se comparent pas de la même façon. Je suis pas bien sur de comprendre ton pb là.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Gaël Le Mignot . Évalué à 2.
Trouve-moi un compilateur qui implémente le C ISO 99 mieux que gcc 3.2 en -std=c99.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Dawm . Évalué à 0.
Maintenant trouve moi un compilateur qui implément l'ISO C++ à 100% :/
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Gaël Le Mignot . Évalué à 2.
Sinon, beaucoup d'extensions GNU ont été reprises dans le C 99, et pour les autres elles correspondent vraiment à des manques dans le standard du C (comme les macros type-safe et effets de bord-safe, ou les macros à arguments variables, ou encore les attributs qui permettent d'avoir une vérification du format ala printf sur des fonctions custom... va voir la doc de gcc pour plus d'info). Maintenant, via les autotools par exemple, tu peux parfaitement détecté la version de ton compilateur et ne pas utiliser les extensions lorsque tu n'as pas gcc. Sauf dans les cas cités au premier paragraphe.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 3.
Ce qui est normal car le language C doit être portable. Les extentions bas niveau ou d'optimisation du i386 ne peuvent peut-être pas être disponible sur un autre hardware.
Enfin, les compilateurs font un très bon travaille d'optimisation automatiquement dans la grand majorité des cas (sauf pour quelque cas comme un noyau, mplayer, etc...). Par exemple l'emploie du mot clé standard register n'est pas très utile.
> ce qui peut être nécessaire dans certaines partie d'un noyau.
C'est surtout que Linux a été fait avec gcc et utilise donc les optimisations de gcc. Linux n'a jamais était fait dans le but d'être compilable par un autre compilateur (et je ne m'en plains pas).
Linux sauf le répertoire arch doit surement être compilable avec un compilateur standard une fois qu'un peu de nettoyage des utilisations des extensions de gcc a été fait.
Le "non respect" des standards par Linux ne pose pas de problème de portage. Il est rare de compiler Linux sous Solaris, Beos, Windows etc... :-)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Gaël Le Mignot . Évalué à 3.
Je n'ai pas dit le contraire, mais utiliser des extensions devient donc nécessaire pour écrire un noyau (ne serait-ce qu'à cause de l'assembleur in-line ou de méthodes spéciales de passage de paramètres).
Enfin, les compilateurs font un très bon travaille d'optimisation automatiquement dans la grand majorité des cas
Je suis parfaitement d'accord, mais encore une fois, quand on touche au trop bas niveau, les optimisations qui normalement ne changent rien peuvent modifier le comportement du programme, d'où la nécessité de pouvoir les contrôller dans un noyau.
Sinon, certaines choses comme les attributes "pure" ou autres de gcc permettent au compilateur de mieux optimiser, et là, via autoconf ou tout simplement le préprocesseur, on peut faire du code portable sur d'autres compilateurs et qui les utilise:
#ifdef __GNU_C
#define __GNU_PURE__ __attribute__((pure))
#else
#define __GNU_PURE__
#endif
et ensuite, il suffit d'utiliser __GNU_PURE__. Mais là on rentre dans un autre débat ;)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 1.
> Sinon, certaines choses comme les attributes "pure" ou autres de gcc permettent au compilateur de mieux optimiser, et là, via autoconf ...
Ce sont des "bidouilles" (je ne critique pas la qualité de ces outils qui sont dans la pratique indispensables pour un programme multi-plateforme) pour optimiser ou gérer les différences d'implémentation des compilateurs. Si le standard C était parfait (mais ce n'est pas impossible) et les optimisation automatique toujours bonnes (et là il faut réver fort), ces pratiques ne seraient pas nécessaire. Je le répète, dans la pratique elles sont indispensables.
> utiliser des extensions devient donc nécessaire pour écrire un noyau
> les optimisations qui normalement ne changent rien peuvent modifier le comportement du programme, d'où la nécessité de pouvoir les contrôller dans un noyau.
En effet le standard C ne propose pas grand chose pour la programmation bas niveau (spécification d'adresse des variables, etc...) et n'est pas adapté pour le developpement du noyau. Il n'y a que le mot clé "volatile" dans la norme qui peut interresser un développeur noyau et le mot clé "register" (inutile vu le niveau des compilateurs mais toujours là pour des raisons historiques) et "inline" (rend aussi le code plus propre en évitant des macros et ajoute le controle de paramètres) pour optimiser du code.
Tout ceci est parfaitement normal. Le language C doit être intépendant du hard et le noyau s'occupe du hard. Les missions du standard C sont différentes du noyau voir incompatibles. Il faut donc passer par des extensions.
Pour les extensions de gcc qui ne sont pas dans la norme. Je les adore alors que j'ai pas fait de développement bas niveau :-). J'ai bossé sur OSF-1, HP-UX, Solaris et j'ai toujours utilisé gcc/gdb/ddd en parallèle avec les outils standards car ils sont bien meilleurs.
Bref tout ce blabla pour dire que l'on est d'accord.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par CMO (site web personnel) . Évalué à 2.
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par matiasf . Évalué à 3.
Chaqu'un son expérience. Moi je préfère gcc etc... Evidament qu'il y a des problèmes comme dans tous les logiciels mais pour moi gcc est meilleur (même si les autres savent souvant mieux utiliser le cpu) :
- Meilleur message d'erreur
- des extensions utiles
- disponible partout (très important çà surtout quand on a la malchance comme moi de travailler sur des fichiers binaires qui doivent être utilisés sur plusieurs plateformes)
- gdb avec gcc est le meilleur debugger (d'ailleur HP utilise gdb maintenant) en ligne.
- ddd avec gdb/gcc est le meilleur debugger graphique (du moins sous Unix). Et là il n'y a pas photo ! Surtout qu'en on voit les trucs tordus, non ergonomique (et faut de l'ergonomie pour debugger car le mode texte comme dbx c'est lourd...) proposés par les Unix commerciaux.
Alors tu dis que gcc y fait pas ci, y fait pas çà. Je confirme gcc n'est pas parfait. Mais j'ai eu aussi des poblèmes avec le compilo HP :
- certains programmes qui utilisent select() compilés avec -O2 ne marchent pas et pas de problème avec gcc. Et d'autres comportements "woodo" avec X11 quand on utilise les optimisations.
- le préprocesseur n'aime pas les grosses macros (quand une macro utilise d'autres macros qui utilisent d'autres macros ...).
Pour Solaris j'ai moins de critique mais il sort parfois des "pointeurs incompatibles" lorsqu'on utilise les const (les doubles const) .
Par contre je n'ai eu pratiquement aucun problème avec le compilateur OSF-1. Les plus gros reproches sont :
- messages d'erreur pas très clair.
- contrôle du code source très léger (variable non initialisé etc...).
Afin les qualités de gmake et sa disponibilité partout est un vrai bonheur. Surtout que les programmes makes sont beaucoup moins compatibles entre eux que le language C/C++.
> As tu deja essayer de debugger du code Fortran...
Non
> De meme avec GNU, tu sais comment ca se passe la gestion des exceptions C++ avec des librairies partages
Non, je n'ai pas de problème. Mais chaqu'un son expérience.
> revenez sur terre les amis !
Ben j'y suis là ... Tu es d'où toi?
> GCC, c'est bien pour compiler des trucs simpes. Mais rien de plus.
Apparament t'es pas de la planète terre. Ou alors pour toi mozilla/Linux/OpenOffice sont des trucs "simple et rien de plus".
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
ddd est pas mal du tout, mais il existe aussi gvd, qui est excellent je trouve :
http://libre.act-europe.fr/gvd/(...)
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Alberto . Évalué à 1.
revenez sur terre les amis !
GCC, c'est bien pour compiler des trucs simpes. Mais rien de plus.
linux, gcc, kde, gnome sont donc des trucs simples ?
De mon temps, le compilo C++ de sun supportait tres mal les templates et la stl, peut etre ca a change depuis...
[^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1
Posté par Herve Lebrie . Évalué à 1.
Je n'ai jamais utilisé g++ professionnellement sauf pour tests uniquement sur HP (32 bits), mais à voir les applis développées avec g++ sous GNU/Linux je ne pense pas qu'on puisse dire qu'il soit un mauvais compilateure.
Tu n'as jamais du être sur terre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.