• # amd

    Posté par (page perso) . Évalué à 10.

    Je l'ai utilisé a l'epoque où il était proprio et où il s'appelait mipspro compiler sur les machines sgi, c'etait il y a plus de 10 ans et c'était un excellent compilateur c++/fortran très en avance sur les autres, avec des trucs genre link-time optimisation , des pragma specifiques pour aider le compilateur a effectuer des optimisations aggressives sur les boucles, et une doc excellente pour expliquer tout ça.

    Il me semble que maintenant il a plutot été adopté par AMD, qui le distribue d'ailleurs: http://developer.amd.com/tools/open64/Pages/default.aspx et qui va l'utiliser pour ses outils OpenCL (a la place de LLVM donc). A confirmer parce que je suis pas trop sur de moi quand même.

    • [^] # Re: amd

      Posté par . Évalué à 3.

      L’université du Delaware est officiellement le gardien (gate-keeper) d'Open64. Je confirme tout ce que tu dis à propos de la qualité du compilateur.

      La représentation intermédiaire d'Open64, SIMPLE, a été l'inspiration de GIMPLE pour gcc.

      Il faut aussi noter qu'il est très utilise par les chercheurs car il proposait des optimisations très avancées pour l’époque (plus que gcc, mais maintenant les deux semblent être à peu près au même niveau pour le cas général -- pour certains cas particulier par contre, Open64 peut être meilleur que gcc et icc).

  • # Benchmark

    Posté par . Évalué à 3.

    Voici un benchmark sous les nouveaux "bulldozer" d'AMD d'une ancienne version.

    http://www.phoronix.com/scan.php?page=article&item=amd_bulldozer_compilers&num=1

    Dommage qu'il n'y est pas ICC dans le comparatif.

    • [^] # Re: Benchmark

      Posté par (page perso) . Évalué à 2.

      Dommage qu'il n'y est pas ICC dans le comparatif.

      Euh, c'est peut-être volontaire car j'ai entendu qu'ICC est juste le compilateur C le plus rapide qui existe actuellement (mais c'est un compilateur proprio).

      • [^] # Re: Benchmark

        Posté par (page perso) . Évalué à 4.

        Oups, je croyais que c'était un benchmark réalisé par les auteurs d'Open64 (ou AMD). En fait non, c'est un site qui est -je crois- indépendant.

      • [^] # Re: Benchmark

        Posté par . Évalué à 5.

        Je crois qu'il est aussi capable de sortir un binaire qui ne fonctionnera pas sur de l'AMD donc ça peut se comprendre.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Benchmark

          Posté par . Évalué à 10.

          ICC est aussi capable de ralentir le code produit, au lieu de l'optimiser, s'il n'est pas exécuté sur un processeur Intel mais AMD ou Via ou autre.
          http://www.agner.org/optimize/blog/read.php?i=49

          • [^] # Re: Benchmark

            Posté par . Évalué à 3.

            Et je suppose que c'est avec ce truc que sont compilés les softs de benchmarks qui font dire à des sites de news hardware (ceux avec la pub Intel qui clignote de partout) que faut acheter du Intel.

            Merci pour ton lien, je le garde précieusement la prochaine fois qu'un fanboy Intel vient me saouler sur PCINpact.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Benchmark

              Posté par (page perso) . Évalué à -2.

              je le garde précieusement la prochaine fois qu'un fanboy Intel vient me saouler sur PCINpact.

              En même temps, PCInpact...

              • [^] # Re: Benchmark

                Posté par (page perso) . Évalué à -1.

                En même temps, LinuxFr...

                C'est pas bientôt fini de rabaisser ce qui est différent de vous?

                • [^] # Re: Benchmark

                  Posté par (page perso) . Évalué à 2.

                  Ben non, spa drôle sinon.

                  (et la critique ne vise pas le site, son contenu, mais les commentaires intelligent qu'on peut y trouver. Par contre, j'ai jamais dit que c'était mieux ici...)

                • [^] # Re: Benchmark

                  Posté par . Évalué à 8.

                  En même temps ce qui est différent de nous …

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Benchmark

                Posté par . Évalué à 1.

              • [^] # Re: Benchmark

                Posté par . Évalué à 1.

                Tiens je rebondis sur ce commentaire pour dire mon ressenti à propos de PCIMPACT : je rouve qu'ils se sont vachement améliorés, vraiment, sur la qualité des articles. Depuis quelques temps j'ai l'impression de lire le pcimpact de 2005. ça fait plaisir.
                Pcimpact, c'est bon, mangeons en.

                • [^] # Re: Benchmark

                  Posté par (page perso) . Évalué à 3.

                  Pcimpact

                  PC INpact. La faute d'orthographe fait partie de la marque.

                  • [^] # Re: Benchmark

                    Posté par . Évalué à 3.

                    J'attends juste qu'un lecteur de Da Linux French Page ose critiquer cette faute volontaire. Venez, l'huile bouillante est prête.

                    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Benchmark

      Posté par . Évalué à 2.

      Ces benchmarks ne sont pas très utiles pour comparer les processeurs ni les compilateurs. Un peu comme les nombreux benchmarks qu'on voit fleurir sous windows, pour comparer vraiment il faudrait au moins que :
      * soit ajoutées aux flags de compilation les options précisant le processeur exact à utiliser (afin d'éliminer le biais lié à un binaire "générique" ou "optimisé pour la majorité des processeurs actuels", qui peuvent varier sensiblement d'un compilateur à l'autre)
      * les programmes ne soient pas seulement compilés avec des flags par défaut valables sur tous les compilateurs mais des tirent parti de flags spécifiques à chacun (si on veut comparer des compilateurs, autant en tirer la quintessence).

      • [^] # Re: Benchmark

        Posté par (page perso) . Évalué à 2.

        La majorité des gens utilisent les flags par défaut, donc si, c'est utile.
        Charge au développeur du compilo d'avoir des flags par défaut qui vont bien dans la majorité des cas (si le développeur se limite à i386 de nos jours, c'est son problème, il peut changer le flag par défaut aussi).

        Est-ce que le binaire fourni marche sur la machine de test? Oui, non. C'est tout. Oui, ca fait un test aussi des flags par défaut, et alors? Ca fait partie du test.

        Après, on peut faire x lignes de test avec x flags, pour comparer si on a envie, c'est juste plus poussé par rapport à l'utilisation classique.

        • [^] # Re: Benchmark

          Posté par . Évalué à 6.

          La majorité des gens s'en fout que le compilo X aille 3% plus vite que le compilateur Y sur l'application bidule, car la majorité des gens ne fait pas de développement et utilise les applications qu'il a sans s'intéresser à leur optimisation. En plus, la majorité des gens changent de matériel dès qu'ils voient un ralentissement, ou alors ont un PC de course pour ne faire que de la bureautique.

          Les seuls gens intéressés par des benchmarks de compilateurs sont ceux qui cherchent la performance, pour des applications bien précises. Pour ces gens là, le comparatif tel qu'il est fait est inutile et je maintiens mes remarques.

        • [^] # Re: Benchmark

          Posté par . Évalué à 0.

          Tu veux dire -march=native ?

          • [^] # Re: Benchmark

            Posté par . Évalué à 2.

            Sous GCC, oui. Mais aussi -flto par exemple pour les veresions de gcc supérieures ou égales à 4.5, éventuellement un profiling si possible/facile.

      • [^] # Re: Benchmark

        Posté par . Évalué à 3.

        A propos de comparatifs de compilos, en voici un bien bien intéressant, malheureusement le developpeur est très occupé avec la supervision et n'a plus trop le temps de le mettre à jour : http://sourceforge.net/projects/compbench/ ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.