Comparatif Intel C++ 7.0 / Gcc 3.2.1

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
7
déc.
2002
Technologie
Coyote Gulch Production propose depuis 3 jours un comparatif entre les deux derniers compilateurs C/C++, a savoir Intel C++ 7.0 et Gcc 3.2.1.
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

  • # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

    Posté par  . Évalué à 10.

    > le compilateur d'Intel genere un code en moyenne 15% plus rapide que celui de Gcc.

    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  (site web personnel) . Évalué à 10.

      Autres points :
      - 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  (site web personnel) . Évalué à 2.

        petit plus en faveur de gcc (encore un :)):
        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  . Évalué à 8.

        Tout à fait..
        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  (site web personnel) . Évalué à 5.

        - les développeurs GCC sont très réactifs (je ne sais pas pour ICC vu que je ne l'utilise pas)

        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  . Évalué à 2.

          > on les attends depuis LONGTEMPS

          TRES LONGTEMPS
          • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

            Posté par  . Évalué à -1.

            il fallait peut-être le faire soi-même au lieu d'ATTENDRE
          • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

            Posté par  . Évalué à 2.

            D'après ce que j'ai compris, ça tombait pas bien avec le calendrier du reste du developpement de gcc (des trucs à modifier avant sur le C++ ou quelque chose comme ça).
            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  (site web personnel) . Évalué à 1.

              Oui, c'est ce que j'avais entendu comme raison à l'époque -- le patch était pour gcc 2.9x donc, comme les types de gcc étaient en train de tout chambouler niveau C++ pour gcc 3.x, ils avaient mis ça de côté -- ce qui peut largement ce comprendre; Mais bon, on en est au 3.2, et Apple a porté son patch sur gcc 3.x aussi ... donc c'est un peu lourd de devoir attendre, encore. Même si on peut comprendre, qu'il y a surement tout un tas de raison, c'est lourd. Voila. Juste pour le noter.
              • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                Posté par  . Évalué à 1.

                Oui mais en fait Apple n'était sans doute pas prêt pour le 3.0 et peut-être pas pour le 3.1 et entre temps la branche 3.2 (le tronc en fait) a été rebaptisée 3.3, tandis que la FSF faisait un 3.2 sur la branche du 3.1 pour avoir les changement d'ABI C++ postérieurs à la 3.1 (sinon toutes les distributions basées sur GCC.3x qui étaient sur le point de sortir, RH8, MDK9 et Suze-pas-libre, auraient utilisé des GCC3.1 patchés, et ça aurait été un beau bordel comme à l'époque ou RedHat avait sont propre GCC avec sa collection perso de patches). Donc vu que le chantier du C++ a continué après la sortie de GCC3.0 et 3.1 finalement ça fait pas si longtemps.
                • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                  Posté par  . Évalué à 1.

                  > sinon toutes les distributions basées sur GCC.3x qui étaient sur le point de sortir, RH8, MDK9 et Suze-pas-libre, auraient utilisé des GCC3.1 patchés Si tu sous-entends que gcc 3.2 est sorti pour faire "plaisir" aux distributeurs, je ne suis pas convaincu (mais je me trompe peut-être). En effet, j'était abonné à la mailing psyche (RH8.0). Au début gcc 3.1.1 devait être utilisé. gcc 3.2 est sorti et quelqu'un a demandé si ce compilateur pouvait être intégré. Les devs RedHat on estimé qu'il n'y avais pas de grosse différence entre la 3.2 et leur version actuelle de la 3.1.1 . RedHat a décidé de mettre la 3.2. Je n'ai pas eu l'impression que le passage en 3.2 était une demande de RedHat ou autre distributeur. De plus la prochaine gcc 3.3 sera imcompatible avec le 3.2. Ce n'est que repousser le problème de quelques mois...
                  • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                    Posté par  . Évalué à 1.

                    De plus la prochaine gcc 3.3 sera imcompatible avec le 3.2. Ce n'est que repousser le problème de quelques mois...

                    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  (site web personnel) . Évalué à 1.

                    beuh !? je croyais qu'ils avaient dit que cette fois c'était sur et certain, gcc-3.2 devait enfin avoir une ABI c++ stable et conforme qui bouge plus ... ils ont changé d'avis ? y'a autre chose ? t'as une url ?
                    • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                      Posté par  . Évalué à 2.

                      Je vous présente toutes mes excuses.

                      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  . Évalué à 1.

          Faut aussi connaitre le pourquoi de cette lenteur pour juger. Peut-être que le team gcc ne veut pas de ce patch car dure a maintenir, n'interesse que peu de monde, etc...
          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  . Évalué à 1.

            Ceci étant dit, ce n'est pas parce que c'est mis en attente que c'est systématiquement bien calculé. En l'occurence, Sebastien à l'air bien renseigné sur « pourquoi de cette lenteur » et donc il est libre de « juger ».
        • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

          Posté par  . Évalué à 2.

          Ca apporte quoi de mixer objc et c++ ?
          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  . Évalué à 2.

            ça fait un langage avec une syntaxe chargée :)
            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  . Évalué à 3.

            >Ca apporte quoi de mixer objc et c++ ?

            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  (site web personnel) . Évalué à 2.

            Ca apporte quoi de mixer objc et c++ ?

            [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  . Évalué à 1.

              Mouais... Est-ce que ce ne serait pas plus intelligent à long terme de porter GNUStep en C++, histoire de s'affranchir de la dépendance à un langage très très peu utilisé, et de donner la possibilité à plus de développeurs de contribuer ?

              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  . Évalué à 5.

                Mouais... Est-ce que ce ne serait pas plus intelligent à long terme de porter GNUStep en C++, histoire de s'affranchir de la dépendance à un langage très très peu utilisé, et de donner la possibilité à plus de développeurs de contribuer ?

                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  . Évalué à -1.

                  > > 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 ?

                  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  (site web personnel) . Évalué à 1.

                    Gcc maintient déjà Ojective C qui n'est pas très utilisé

                    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  . Évalué à 1.

                      > c'est quand même le langage par défaut sous Mac maintenant... Quoi ? l'Ojective C ou le "Ojective C avec C++" . > Mais bon, à l'extrème on ne touche plus à rien alors. OK. Mais non. Les devs Apple GnuStep peuvent modifier gcc (c'est évidant). Le problème est l'acception par gcc d'un patch. Je vois quoi sur ce "forum" : - une personne qui se plaint de la lenteur d'acceptation d'un patch. - pas d'explication. c-à-d les raisons du refus, ou l'absence de réponse, etc... Bref il fait une critique sur l'équipe gcc sans réel fondement (du moins sans explication suffisante) : gcc n'est pas réactif d'ailleur le patch [...] on attend depuis <B>LONGTEMPS</B>. Je voulais souligner qu'étant distant du problème je ne vois pas en quoi gcc est critiquable et implicitement rejeter cette critique qui est limite gratuite. Je crois que tout çà tu l'as compris... Mais je dis çà et je ne fais pas avancé le schmilblic (c'est quoi l'orthographe?).
                  • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                    Posté par  . Évalué à 2.

                    C'est ridicule. La partie Objc est essentiellement maintenue par l'équipe GCC d'Apple, qui de toute façon en a besoin puisque c'est un des piliers de leur système. L'intérêt d'un langage se mesure pas à son omniprésence dans la presse pour décideurs pressés ; c'est quoi cette attitude maintenons-seulement-les-langages-populaires ? Peut-être que l'équipe de GCC devrait plutôt se focaliser sur la création d'un environnement basic compatible VB ? Je me suis laissé dire qu'il avait des légions de "programmeurs" qui adorent cet environnement. l'Objective-C existe depuis les années 80 et est supporté dans GCC depuis des lustres. Il n'a AUCUNE raison de ne pas maintenir ce langage sous pretexte qu'il serait pas aussi populaire que le C++. Le jour ou la popularité sera le principal souci des leaders du dev GCC, je le jette (de toute façon, ce jour là, ils se focaliseront sur le portage windows et écouterons en boucle la star-academy 22e version sur une chorégraphie inventée par les auteurs de CAML - qui auront été obligés de se reconvertir à cause du manque de popularité de leur langage ;o) ).
                    • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                      Posté par  . Évalué à 2.

                      C'est quoi ce troll de collégien ? Personne n'a reproché à gcc d'inclure Objective-C. Le reproche initial était que gcc n'intégrait pas assez rapidement les patches d'Apple. Je remarque en passant que personne n'a précisé : - si Objective C était normalisé - si le fait d'inclure du C++ dans un programme Objective C faisait partie de la norme, ou était une extension ésotérique Sans argumentation supplémentaire, il n'y a pas de raison qu'une fonctionnalité qui ne profite qu'à un groupe de développeurs bien particulier soit automatiquement acceptée et maintenue par l'équipe de gcc. Je partage entièrement l'opinion de Feliciano sur le sujet. de toute façon, ce jour là, ils se focaliseront sur le portage windows et écouterons en boucle la star-academy 22e version sur une chorégraphie Mais oui, mais oui, surtout évite de dire qqch d'intéressant....
                      • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                        Posté par  . Évalué à 2.

                        - si Objective C était normalisé - si le fait d'inclure du C++ dans un programme Objective C faisait partie de la norme, ou était une extension ésotérique L'Objective-C est un sur-ensemble du C qui lui est normalisé ISO/IEC. Donc à proprement parler, l'Objective-C n'est pas normalisé (à ma connaissance). Et c'est la même chose pour l'Objective-C++. Maintenant, il y'a une sorte de standard en ce qui concerne l'Objective-C : http://pages.cpsc.ucalgary.ca/~burrellm/objc/objc.html Je ne vois pas de toute façon de justification à propos de ce patch dans le fait que l'Objective-C soit normalisé ou pas. Après tout ça ne fait pas si longtemps que le C++ est normalisé (1997 je crois), en suivant ton raisonnement toutes les améliorations au C++ n'aurait pas du être intégrées. Ce patch est, à mon avis, une attente légitime dans la mesure GNUStep est un projet qui vit et qui risque de prendre de l'ampleur mais tu remarqueras que tous les devs GNUStep et les autres (dont je fais partie) sont patients et mesurés concernant ce patch. En plus, en comptant les devs Apple, la "communauté" Objective-C n'est pas aussi restreinte que ce que tu penses. Donc voilà, ce patch est intéressant et de toute façon on attendra ;-)
                    • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                      Posté par  . Évalué à 1.

                      > c'est quoi cette attitude maintenons-seulement-les-langages-populaires ? Je crois que tu m'as pas compris. Pour moi c'est principalement un problème de maintenance par l'équipe gcc et peut être un problème de qualité du patch (je ne le connais pas). Si le language est populaire l'équipe gcc, tous les contributeurs, peuvent accepter la contrainte de prendre en compte cette fonctionnalité lorsqu'ils font des modifications. Si ce n'est pas le cas, faut-il "ennuyer" tous les contributeurs pour une fonctionnalité peu utilisée ? Ou n'est-il pas mieux de laisser la maintenance du patch à ceux qui l'on réalisé. Sur l'aspect popularité c'est tout ce que je dis. Je souligne aussi : > que je ne connais pas tout les tenants et aboutissants du problème. Tu remarquera que Linus a les même problème de chois avec Linux. Certaines fonctionnalités ne sont pas acceptés car elles alourdissent le boulot des autres développeurs. D'autres fonctionnalités sont acceptés même si elles sont loin d'être parfaite car elles n'impactent pas les autres développeurs. D'autres patchs sont refusé car il n'apporte rien d'important. Les distributeurs ont leur lot de patch pour le kernel non accepté par Linus et faut-il conclure que Linus est lent ou autre ? Bref il y a plein de raison pour le(s) mainteneur(s) d'accepter ou refuser un patch. Dire que gcc n'est pas réactif uniquement parce qu'ils n'ont pas accepté un patch est un peu léger pour me convaincre.
                • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                  Posté par  . Évalué à 1.

                  Crois tu qu'un développeur C puis C++ peut facilement s'adapter à objc, pas au niveau syntax mais à la logique du langage, la facon de concevoir une applie est elle vraiment différente qu'en C++ ? Est ce que ObjC a autant de comportements indéfinies et effet de bords que le C&C++ ?
                  • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                    Posté par  (site web personnel) . Évalué à 1.

                    Au niveau syntaxe, il y a UNE addition syntaxique par rapport au C ... donc effectivement, ça va vite ;)
                    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  (site web personnel) . Évalué à 4.

                Est-ce que ce ne serait pas plus intelligent à long terme de porter GNUStep en C++

                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  . Évalué à 1.

        Tu oublies le plus important: gcc compile du C, C++ , Ada, fortran77, Java. Il existe pour de nombreuse plateforme. Au fait: gcc = GNU Compiler Collection
    • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

      Posté par  . Évalué à 3.

      Effectivement. Et celui qui redige a, ou mal lu l'article, ou cherche a faire un troll, ce qui n'est pas beaucoup mieux.

      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  . Évalué à -1.

      > > le compilateur d'Intel genere un code en moyenne 15% plus rapide que celui de Gcc.
      > 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  (site web personnel) . Évalué à 10.

    Il y a quelques jours j'avais fait un test sur la compilation de Lame. Il s'avérait que la version compilée avec ICL7 était moins rapide que celle compilée avec GCC2.95 sur pentium II. La différence n'était pas flagrante, mais d'environ 1 à 2 %.
    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  (site web personnel) . Évalué à 10.

    Les bench ça vaut ce que ça vaut mais bon, les perf affichées pour le scimark me paraissent vraiment mauvaises pour un pIII-600 qui est censé savoir faire 42 choses à la fois tout en accelerant l'internette: 100MFlops pour une factorisation LU (juste une série d'additions multiplications bien bourrine) c'est vraiment pas terrible. D'autant qu'il ne fait pas trop intervenir le cache puisque la matrice en question est 100x100 soit 80ko d'occupation mémoire ça loge à peu près dans n'importe quel cache L2.

    [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  (site web personnel) . Évalué à 1.

      ah oui, et si quelqu'un avec un pentioume-4 pouvait lancer le bench (les sources C sont là http://math.nist.gov/scimark2/scimark2c.zip(...) ), ça m'interesserait de connaitre les resultats, que ce soit avec gcc ou icc (ou même bcc, le compilateur de borland est dispo sous linux, non?)
      • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

        Posté par  . Évalué à 4.

        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: 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  (site web personnel) . Évalué à 1.

          merci, ça c'est plutot interessant, même si ta version de gcc est un peu vieille.. t'as bien compilé avec -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math ?
          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  . Évalué à 2.

            Non, j'avais fait un make (donc avec les options préreglées)

            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  . Évalué à 1. Dernière modification le 05 décembre 2021 à 17:55.

              autre P4

              <pseudo>@atlobk01:~/tmp$ ./scimark2  
              **                                                              **  
              ** SciMark2 Numeric Benchmark, see [http://math.nist.gov/scimark(...)](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:          303.78  
              FFT             Mflops:   127.13    (N=1024)  
              SOR             Mflops:   304.90    (100 x 100)  
              MonteCarlo:     Mflops:    52.43  
              Sparse matmult  Mflops:   463.15    (N=1000, nz=5000)  
              LU              Mflops:   571.27    (M=100, N=100)  
              
              
              
              <pseudo>@atlobk01:~/tmp$ cat /proc/cpuinfo   
              processor       : 0  
              vendor_id       : GenuineIntel  
              cpu family      : 15  
              model           : 2  
              model name      : Intel(R) Pentium(R) 4 CPU 2.00GHz  
              stepping        : 4  
              cpu MHz         : 2019.958  
              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        : 4023.91
              
              • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                Posté par  . Évalué à 1.

                Je dois dire que j'ai quelques difficultés pour interpreter ces résultats... Un peu bizarre, non, une machine à 2Ghz qui fait moins qu'un Athlon à 1.4Ghz, si c'est dans ce sens qu'on doit le prendre.

                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  . Évalué à 1.

                  Ca tombe bien, j'ai un Athlon 2000 (1667 MHz) :

                  $ ./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  . Évalué à 1.

                    Moi aussi je peux jouer ?

                    [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  (site web personnel) . Évalué à 2.

                  euh ben moi aussi j'ai un peu de mal à interpreter sur la fin :) visiblement sur les plus hautes fréquences les perfs s'équilibrent entre l'athlon et le p4, j'imagine qu'il doit y avoir un goulet d'etranglement genre le débit du cache de niveau 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  (site web personnel) . Évalué à 2.

                  Gcc n'aime pas les piles (gcj a un backend spécial) or le code x87 utilise une pile. Gcc utilise une instruction spécial qui va chercher les bonnes valeur dans la pile plutot que de scheduler les opérations pour une pile.

                  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  . Évalué à 1.

                Avec les options en plus

                ** **
                ** 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  . É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

                  moa@dionysos:~/tmprm$ scimark2   
                  **                                                              **  
                  ** SciMark2 Numeric Benchmark, see [http://math.nist.gov/scimark(...)](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:          311.14  
                  FFT             Mflops:   204.72    (N=1024)  
                  SOR             Mflops:   246.41    (100 x 100)  
                  MonteCarlo:     Mflops:    42.34  
                  Sparse matmult  Mflops:   405.80    (N=1000, nz=5000)  
                  LU              Mflops:   656.41    (M=100, N=100)  
                  

                  Avec gcc-3.2

                  moa@dionysos:~/tmprm$ ./scimark2   
                  **                                                              **  
                  ** SciMark2 Numeric Benchmark, see [http://math.nist.gov/scimark(...)](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:          319.72  
                  FFT             Mflops:   197.31    (N=1024)  
                  SOR             Mflops:   238.48    (100 x 100)  
                  MonteCarlo:     Mflops:    44.89  
                  Sparse matmult  Mflops:   461.52    (N=1000, nz=5000)  
                  LU              Mflops:   656.41    (M=100, N=100)  
                  

                  Sur le P4 2Gh

                  <pseudo>@atlobk01:~/tmp$ ./scimark2   
                  **                                                              **  
                  ** SciMark2 Numeric Benchmark, see [http://math.nist.gov/scimark(...)](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:          388.10  
                  FFT             Mflops:   249.18    (N=1024)  
                  SOR             Mflops:   302.98    (100 x 100)  
                  MonteCarlo:     Mflops:    51.82  
                  Sparse matmult  Mflops:   514.01    (N=1000, nz=5000)  
                  LU              Mflops:   822.49    (M=100, N=100)  
                  

                  et avec gcc 3.0

                  <pseudo>@atlobk01:~/tmp$ ./scimark2   
                  **                                                              **  
                  ** SciMark2 Numeric Benchmark, see [http://math.nist.gov/scimark(...)](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:          417.00  
                  FFT             Mflops:   242.93    (N=1024)  
                  SOR             Mflops:   372.00    (100 x 100)  
                  MonteCarlo:     Mflops:    51.82  
                  Sparse matmult  Mflops:   595.78    (N=1000, nz=5000)  
                  LU              Mflops:   822.49    (M=100, N=100)  
                  

                  sur un biproc GenuineIntel Pentium III (Coppermine) 796.553

                  avec gcc 2.95.4

                  **                                                              **  
                  ** SciMark2 Numeric Benchmark, see [http://math.nist.gov/scimark(...)](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:          174.09  
                  FFT             Mflops:   118.82    (N=1024)  
                  SOR             Mflops:   239.67    (100 x 100)  
                  MonteCarlo:     Mflops:    33.22  
                  Sparse matmult  Mflops:   206.74    (N=1000, nz=5000)  
                  LU              Mflops:   271.98    (M=100, N=100)  
                  

                  et avec gcc 3.0

                  <pseudo>@subversions:~/tmp&gt; ./scimark2   
                  **                                                              **  
                  ** SciMark2 Numeric Benchmark, see [http://math.nist.gov/scimark(...)](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:          182.24  
                  FFT             Mflops:   127.88    (N=1024)  
                  SOR             Mflops:   267.63    (100 x 100)  
                  MonteCarlo:     Mflops:    36.57  
                  Sparse matmult  Mflops:   213.47    (N=1000, nz=5000)  
                  LU              Mflops:   265.63    (M=100, N=100)  
                  

                  finalement, sur un PII (Deschutes) 350 avec gcc 3.2

                  (en fait gcc-3.2-base 1:3.2.1-0pre3)

                  Using       2.00 seconds min time per kenel.  
                  Composite Score:           54.91  
                  FFT             Mflops:    47.60    (N=1024)  
                  SOR             Mflops:    90.21    (100 x 100)  
                  MonteCarlo:     Mflops:    13.75  
                  Sparse matmult  Mflops:    60.24    (N=1000, nz=5000)  
                  LU              Mflops:    62.75    (M=100, N=100)  
                  

                  Beuh…

      • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

        Posté par  . Évalué à 2.

        Sur mon athlon XP2200+ (1800 MHz), compilé avec gcc 3.2.1 et les options que tu donne (-O3 -funroll-all-loops -fomit-frame-pointer -ffast-math) j'obtient

        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  . Évalué à 2.

          Et donc (cf message plus haut) même sans les optimisations mon XP2200+ à 1800MHz bat à tous les test un P4 2GHz!

          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  (site web personnel) . Évalué à 1.

        Bon, j'ai fait également quelques tests...


        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  (site web personnel) . Évalué à 2.

          effectivement c'est un peu gros avec bcc ;-) J'opterai pour un problème avec la mesure du temps (un melangeage entre CLOCKS_PER_SEC , CLK_TCK et sysconf(_SC_CLK_TCK) , je dis ça parce que je me suis déjà embrouillé dans ces trucs)
          • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

            Posté par  (site web personnel) . Évalué à 1.

            Ben si t'as une modification à proposer du code du bench, je veux bien tester... Là, j'ai pas le temps de bidouiller dedans (révision examens)... Mais je peux faire un make et t'envoyer les résultats...
            • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

              Posté par  (site web personnel) . Évalué à 1.

              pareil j'ai la flemme d'autant qu'en divisant tous tes chiffres par 1,000,000 (pile poil la valeur de CLOCKS_PER_SEC) on retombe sur des resultats tout à fait vraisemblables (quoique pas très glorieux pour bcc, mais il n'a pas non plus la réputation de produire un code ultra-rapide)
        • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

          Posté par  (site web personnel) . Évalué à 1.

          Je viens de réaliser le même test sur la même machine (celeron 1200), mais sous windows... Donc où le compilateur Borland est sensé être dans son élément ! La version de BCC est légèrement plus ancienne : Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland et CFLAGS = -6 -O2 -ff Voici les résultats (et là, les conversions sont correctes) : Composite Score: 139.83 FFT Mflops: 60.99 (N=1024) SOR Mflops: 243.61 (100 x 100) MonteCarlo: Mflops: 42.02 Sparse matmult Mflops: 175.46 (N=1000, nz=5000) LU Mflops: 177.09 (M=100, N=100) Pas bien brillant ! Je suis très étonné, je pensais que le compilateur de Borland était meilleur que ça...
    • [^] # Les options, ça change tout :

      Posté par  . Évalué à 2.

      Voila ce que ça donne sur mon P4 2,26Ghz 1Go RAM :

      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  . Évalué à 1.

        Personne n'a essayé l'option -mfpmath=sse de gcc?
        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  . Évalué à 2.

    Pour ceux que les bench amusent, je me permet d'ajouter cette page qui propose des benchmarks (charge cpu et mémoire) sur pleins de langages (c (gcc), java, ocaml, ruby, perl, ...) pour pleins de taches (gestion exeptions, threads, arithmétique entiere, flotante, recursivité, expressions régulières....)
    Lecture plus que recommandée.

    http://www.bagley.org/~doug/shootout/(...)
  • # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

    Posté par  . Évalué à 2.

    Interressant ce bench !
    Mais comment se fait il que icc 7.0 soit moins performant sur quasiemment tout les tests que icc 6.0 ???
  • # +15% - quel intérêt ?

    Posté par  . Évalué à -1.

    Il semble que même si GCC génère du code compilé 15% moins rapide que le compilo Intel, ça n'a strictement aucune espèce d'importance. 15% de différence au niveau rapidité me semble totalement dérisoire au regard des perfs des machines actuelles, sauf peut-être pour du travail de travail intensif quand ça doit prendre des heures... c'est vrai que 1h30 gagnée sur 10 heures de calcul, pourquoi, et encore...

    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  . Évalué à 3.

      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...)

      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  . Évalué à 1.

        Si effectivement le but du java était de compiler une seul fois, le but premier était d'avoir un programme tournant sur de multiples platteformes de manière aisée. Qu'en est il à ce jour ? Le jre officiel tourne sous windows, linux, macos, probablement quelques autres architectures. Sur FreeBSD par exemple on attend tjs un JRE récent stable et un petit peu supporté par Sun.

        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  (site web personnel) . Évalué à 3.

          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.

          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  . Évalué à 3.

      Juste pour dire que gcc n'est pas globalement plus lent de 15 % que le compilo Intel.
      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  . Évalué à 2.

    Dans le meme ordre de choses, je cherche depuis un moment la meme comparaison entre gcc 2,x ou 3,x et Sun CC 5,x sur architecture sparc .

    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
  • # Prix compilo Inter C++

    Posté par  . Évalué à 2.

    Une license : 400 €
    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  . Évalué à 1.

      Bonjour,

      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  . Évalué à 1.

        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 ?

        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  . Évalué à 3.

    Le principal attrait du compilateur d'Intel, par rapport au compilateur de GNU, est le support des directives OpenMP. Celles-ci apportent une aisance plus importante que celles provenant de MPI (ou PVM) dans le cadre de la parallélisation. D'ailleurs comment se fait-il que ces directives ne soient pas intégrées dans les compilateurs de GNU ? Cela est-il lié à des versements de royautés ?
    • [^] # Re: OpenMP

      Posté par  (site web personnel) . Évalué à 3.

      un mail pas trop vieux à ce sujet: http://gcc.gnu.org/ml/gcc/2002-03/msg01661.html(...)

      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  . Évalué à 2.

        Ben ... la difficulté n'est pas d'écrire le parser de C/C++/Fortran OpenMP. Le langage est bien détaillé dans la spec, tout ça. La difficulté c'est d'écrire un environnement d'exécution potable qui ne bousille pas les perfs. Après il faut aussi faire savoir à l'optimiseur quel genre de truc marchent bien sur la plateforme. C'est assez difficile, surtout que la spec OpenMP est un petit peu ambigüe sur certains points.

        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  . Évalué à 4.

    Honnêtement, j'aimerais savoir quel est l'intéret, pour Intel, de développer leur propre compilateur non-libre plutôt que de participer à gcc. En effet, Intel vend du matériel, et leur intéret est que les programmes tournent mieux sur leurs processeurs que sur ceux des concourrents, donc que les compilateurs, et en particulier un compilateur autant utilisé que gcc, produisent du code optimisé pour leurs processeurs.

    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  . Évalué à 2.

      > Si quelqu'un a un début d'explication
      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  . Évalué à 2.

      C'est tres simple.
      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  . Évalué à 5.

    "Les sources de Linux contiennent en effet pas mal de directives Gcc, et empêchent la compilation par tout autre compilateur."

    <troll>
    quelle merde, ce gcc avec ses extensions propriétaires !
    </troll>
    • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

      Posté par  . Évalué à 1.

      Pas si trollesque que ça.
      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  (site web personnel) . Évalué à 0.

        <troll>

        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  . Évalué à 1.

          Tu peux faire l'effort d'assumer tes propos plutot que de les encadrer de bornes débiles.

          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  . Évalué à 1.

        Je suis d'accord là dessus, à mort les compilateurs aux extensions non standards, qu'ils s'apellent Visual C++ ou GCC. Au lieu d'inventer des trucs, qu'ils implémentent déjà la norme à 100%
        • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

          Posté par  (site web personnel) . Évalué à 2.

          dans le genre d'extension subtiles qui m'ont posés pb pour un projet c++, la comparaison des char*.
          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  . Évalué à 1.

            c++ builder, qui lui se contente de comparer les pointeurs... et gcc compare les chaines pointés, c'est completement differents. Si c'est vrai c'est un bug, mais à mon avis c'est plutôt toi qui as fait une connerie. Ce serait vraiment trop gros. 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; Tu peux certainement t'en sortir en deux temps : class maClasse { static const int COIN; } int maClass::COIN = 42;
          • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

            Posté par  . Évalué à 1.

            Pour le static const int, GCC ne le prend pas non plus :
            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  (site web personnel) . Évalué à 1.

            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.


            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  . Évalué à 2.

          Au lieu d'inventer des trucs, qu'ils implémentent déjà la norme à 100%

          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  . Évalué à 2.

        Il n'y a pas grand chose dans la norme du C qui permette de faire certaines choses de très bas niveau, ou de contrôler le travail de l'optimisation, ce qui peut être nécessaire dans certaines partie d'un noyau.

        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  . Évalué à 3.

          > Il n'y a pas grand chose dans la norme du C qui permette de faire certaines choses de très bas niveau, ou de contrôler le travail de l'optimisation

          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  . Évalué à 3.

            Ce qui est normal car le language C doit être portable.

            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  . Évalué à 1.

              Mon commentaire n'était pas une attaque de ton commentaire mais un complément. Ce que tu as dit est juste.

              > 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  (site web personnel) . Évalué à 2.

                >> 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. Faut arreter l'evangelisation bete et mechante ... As tu deja essayer de debugger du code Fortran dans une librairie partagee appelle par du code C, le tout compile avec GNU et debugger avec GNU ?? Essaye, ensuite, tu vas vite comprendre pourquoi les outils Solaris sont bien meilleurs : avec eux, ca marche, avec GNU, ca marche presque ... des fois... De meme avec GNU, tu sais comment ca se passe la gestion des exceptions C++ avec des librairies partages (so) ... et bah ca se passe tres mal. Y a des fois meme un catch(...) il rattrape rien du tout, si l'exception est definie dans un shared object, qu'elle est declanche dans un autre, et finallement tenter d'etre attrape dans un troisieme. Je n'ai jamais rien vu de semblable sur Solaris ! Ce bug est connu depuis 4 ans sur GNU (voir la mailing list) ... voila un belle exemple de la reactivite, de la communaute opensource ... revenez sur terre les amis ! GCC, c'est bien pour compiler des trucs simpes. Mais rien de plus.
                • [^] # Re: Comparatif Intel C++ 7.0 / Gcc 3.2.1

                  Posté par  . Évalué à 3.

                  > Faut arreter l'evangelisation bete et mechante ...

                  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  . Évalué à 1.

                  Tu fais trop de lib partages.

                  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  . Évalué à 1.

                  Faut, gcc est un bon compilateur, je l'ai utilisé pour écrire des applis HPUX/SCO, les performances étaient correctes et le portage quasi rien n'à faire (+ de pbl au niveau du shell et bugs avec Interface Oracle).
                  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  . É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.