Journal Premières évaluations publiques d'un serveur non-IBM à base de Power8

Posté par  . Licence CC By‑SA.
18
14
avr.
2015

Salut cher Nal mais néanmoins lecteur,

je reprends à mon compte une url postée hier sur la tribune par une moule dont je tairai le nom.

Tout d'abord l'URL :

http://lvalsan.web.cern.ch/lvalsan/processor_benchmarking/presentation/#/title

Que nous apprend cette URL ? Il s'agit de comparatifs référenciels (benchmark) entre plusieurs serveurs & architectures.

Le but étant de comparer le classique x86 aux alternatives que sont Power et arm64.

Si on devait faire un résumé, on pourrait dire que le power8 obtient les meilleures performances en général mais sans surclasser outrageusement ses concurrents, et cela au prix d'une consommation d'énergie bien supérieure.

Le rapport perf/watt est donc en défaveur du power8, il en est d'ailleurs de même pour l'arm64.

Que faut-il penser de la place du power8 dans le datacenter ?

À n'en pas douter, certaines charge de travail (workload) profiteront grandement de cette puissance brute au sein d'un même châssis (montée en charge verticale).

On pourra aussi consolider pas mal de VM (ou LPAR) et/ou conteneur (voir l'offre OVH à base de p8), et donc offrir une plus grande densité de consolidation.

Mais est-ce que cela va renverser la vapeur de l'ogre intel ?

J'en doute beaucoup car les modèles d'applis qu'on nous vend comme étant le futur, tendent plutôt vers des grilles de nœuds banalisés (scalabilité horizontale).

Le futur qu'on nous promet, en tous cas de ce que j'ai compris (mais surtout survolé) d'Apache Mesos, c'est une hétérogénéité de nœuds offrant chacun une puissance et des services variables. On pourrait par exemple confier certains travaux lourds à des p8 de manière totalement transparente aux applis "frontales".

En tous les cas, les bonnes vieilles applis dites "legacy" (comme on les appellent) sont encore légion, et il faudra bien répondre à leur besoins.

Et vous ? Qu'avez-vous comme applis en prod ?
```

  • # L'ergonomie du site

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

    Je ne sais pas pour vous mais moi je n'aime pas du tout l'ergonomie du site (en plus la barre espace ne fonctionne pas chez moi)

    Que faut-il penser de la place du power8 dans le datacenter ?

    Une place de luxe car comme dans les avions ce sont toujours ceux qui coûtent le plus cher qui ont les meilleurs places :-D

    kentoc'h mervel eget bezan saotred

  • # Merci, et une question

    Posté par  (site web personnel) . Évalué à 8. Dernière modification le 14 avril 2015 à 16:03.

    Intéressant de voir qu'il y a quand même un gros problème d’intérêt (ne consomme pas moins, n'est pas plus puissant, alors que ça n'a pas l'air moins cher…) à part le "vendor lock-in"

    Je me pose une question :

    On pourra aussi consolider pas mal de VM (ou LPAR) et/ou conteneur (voir l'offre OVH à base de p8), et donc offrir une plus grande densité de consolidation.

    C'est comparé avec un E3, forcément max 4 cores.
    Mais les E7 peuvent avoir jusqu'à 15 cores. Donc 30 threads.
    Donc comparé à 32 threads (sur 8 cores!) du P8, en quoi le P8 a-t-il un avantage en densité?

    Je cherche toujours un intérêt… Intel a l'air de sacrément cogner en perf/watt contrairement à ce qu'on fantasme quand on voit ARM qui parle de conso (conso faible, oui, mais à quel prix en perf… Donc à part en mobilité où on ne peut pas mutualiser…)

    PS : à noter que c'est aussi comparé à ARM, ce qui rend le test très très intéressant, car on a 3 architectures testées avec le même protocole. Un plaisir pour qui chercher à savoir ce que vaut un CPU en conditions presque réelles avec de la perf/W pour tout type de CPU "connu" (manque juste les prix!). Dommage de ne pas l'avoir mis dans le titre pour être plus précis, ça limite la portée du lien qui est encore plus intéressant que ce que dis le journal.

    • [^] # Re: Merci, et une question

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

      J'ai quand même très peur de la mention "scaled to 2.4 ghz", qui ne veut rien dire. Ajouter des étages de pipelines permet d'augmenter la fréquence du processeur, mais augmente aussi sa latence en cas d’événement spécial (== est moins efficace par cycle d'horloge moyen).

      Je serais curieux de voir les performances d'un SoC arm 64 bits optimisé pour la base consommation et non la puissance (genre Cortex A7, optimisé pour des basses tensions) en grand nombre sur un même die.

      Si on prends un chip ARM optimisé un peu pour les performances, il embarque tout un tas de silicium pour gérer la taille du pipeline (out of order et autre), si en plus on l'optimise pour la puissance, des chemins seront dupliqué (c'est aussi pour ça qu'un cpu rapide à 50% de sa fréquence max à peu d'intérêt, et que ARM a créé les big-little).

      Par contre, si on prend un bon cpu sans rien de trop, bien optimisé en surface et en basse consommation, il peut avoir un rendement énorme (perf/watt & perf/surface). On peut ensuite en mettre "plein".

      "La première sécurité est la liberté"

      • [^] # Re: Merci, et une question

        Posté par  . Évalué à 3.

        C'est mon problème avec ce benchmark:

        1. Je ne sais pas quel code a été utilisé pour faire les benchmarks
        2. Je ne comprends pas leurs métriques en termes de perfs (pour la puissance, c'est assez clair)

        Bref, j'aimerais avoir quelqu'un qui m'explique un peu comment lire les graphes.

        • [^] # Re: Merci, et une question

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

          Je ne sais pas quel code a été utilisé pour faire les benchmarks

          C'est dans le titre du graphe :
          - HEP-SPEC06: http://w3.hepix.org/benchmarks/
          - Geant4 ParFullCMS : http://geant4.cern.ch/
          En gros ce sont des benchmarks qui correspondent à leurs besoins. Ce ne sont pas des benchmarks pour choisir son prochain VPS.

          Je ne comprends pas leurs métriques en termes de perfs (pour la puissance, c'est assez clair)

          Ensuite, HEP-SEC06 te donne un score global, plus il est élevé mieux c'est. Pour comparer les architectures entre elles, ils divisent par le nombre de coeurs et/ou la fréquence, et choisissent une fréquence arbitraire, 2.4GHz.
          Dans leur système final, ils compteront en nombre de core, pas vraiment en nombre de serveurs. Et la perf en fonction de la fréquence, c'est grosso-modo linéaire.
          Pour eux c'est plutôt pour préparer le futur…

          • [^] # Re: Merci, et une question

            Posté par  . Évalué à 4.

            Et la perf en fonction de la fréquence, c'est grosso-modo linéaire.

            Ben non. Il y a d'autres facteurs qui impactent les performances, par exemple les latences d'accès à la mémoire.
            Par ailleurs la capacité à monter en fréquence fait partie de la micro-architecture utilisée, ça n'a pas de sens de "normaliser" ce paramètre. Si le Xeon monte plus en fréquence que l'ARM64, c'est un avantage en faveur du Xeon…

            • [^] # Re: Merci, et une question

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

              Ben non. Il y a d'autres facteurs qui impactent les performances, par exemple les latences d'accès à la mémoire

              C'est vrai pour la mémoire externe (DDR…), moins pour la mémoire on-chip. Dans le cas des codes utilisés ici avec pas mal de localité temporelle et spatiale, c'est pas idiot.
              Ca leur permet de caractériser les architectures pour leurs besoins. En fonction du ratio FLOPS vs B/s ils vont regarder soit la bande-passante mémoire (eg. TRIAD), soit les perfs en compute (c'est plutôt le cas ici).

          • [^] # Re: Merci, et une question

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

            "Pour eux c'est plutôt pour préparer le futur…"

            C'est un peu complètement stupide. Le P4 montait haut en fréquence mais était bien moins efficace que le P3.

            Cela ne peut servir pour comparer 2 architectures différente de CPU.

            "La première sécurité est la liberté"

            • [^] # Re: Merci, et une question

              Posté par  (site web personnel) . Évalué à 3. Dernière modification le 15 avril 2015 à 12:13.

              Désolé, mais c'est loin d'être complètement stupide : c'est "juste" une façon de pouvoir comparer.
              Pas la meilleure, mais on fait avec le moyens du bord. Pourquoi? Parce que d'autres critères sont non publics et aléatoires (genre le prix), alors que les GHz sont assez stables et publics.

              Ca permet alors ensuite de comparer les prix (par GHz) et avoir par ricochet la perf/€, par exemple, avec les données non publiques que tu as.

              Il faut bien choisir un centre de comparaison (stable et publique). Si tu as une autre méthode pas "complètement stupide", on t'écoute! Facile de critiquer, plus difficile de proposer (une solution que d'autres ne trouveront pas "complètement stupide" ;-) ).

              A noter qu'ils comparent aussi la perf par Watt, un autre critère, très intéressant car ça impacte énormément la densité possible dans un DC (et ça fait mal, très mal, autant pour Power8 que pour ARM)

              • [^] # Re: Merci, et une question

                Posté par  . Évalué à 2.

                on peut jouer sur les mots encore longtemps.

                On pourrait aussi parler de perf / m² et là le power8 surclasse certainement tous les autres…vu que sa performance par core explose tout.

                Le critère perf / watt est certes important mais je connais beaucoup de boites où ce critère n'est pas prépondérant, du moins tant que l'énergie électrique en France reste bon marché (ce qui est de moins en moins vrai avec le coût de démantèlement des centrales…)

                • [^] # Re: Merci, et une question

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

                  On pourrait aussi parler de perf / m² et là le power8 surclasse certainement tous les autres…vu que sa performance par core explose tout.

                  Tu peux le garantir?
                  Ca dépend des Watts consommés aussi à ma connaissance (problème de dissipation)

                  Le critère perf / watt est certes important mais je connais beaucoup de boites où ce critère n'est pas prépondérant, du moins tant que l'énergie électrique en France reste bon marché

                  Et leur critère est la perf par core, tu es sûr?
                  Je ne connais pas foule qui a ce critère dans notre monde qui passe de plus en plus au parallélisme (quand ça monte trop, pas mal de monde met un n-ième serveur en fait, en plus ça fait load balancing failover tout ça), plutôt accès sur le prix (qui comprend la surface, la perf/W etc).

                  que l'énergie électrique en France reste bon marché

                  Tu penses qu'il ne s'agit que d'énergie électrique à acheter… OK, OK…
                  (Hint : coût de la clim')

                  • [^] # Re: Merci, et une question

                    Posté par  . Évalué à 2.

                    Tu peux le garantir?

                    Au risque de me répéter, va lire un de mes journaux sur les perf du p8.

                    Je te laisse en outre trouver les bench sur la toile.

                    Puis enfin, tu ne semble pas au courant de ce qu'est le core factor d'Oracle.
                    A ton avis pourquoi oracle facture plus cher le core power que le core intel ?

                    Crois-tu que c'est juste pour faire chier big blue ? Cela reste dans le domaine du possible cela dit :-)

                    Et leur critère est la perf par core, tu es sûr?

                    Ne me fait pas dire ce que je n'ai pas dit.

                    Je dis juste que le critère perf/watt n'est pas forcément un crière prépondérant puisque l'énergie reste bon marché.

                    Mais sinon en quoi l'indicateur de perf/core t'empêcherait de faire du parallélisme ?

                    Tu peux très bien faire tourner du code multithread sur un seul core et comparer avec les autres archi.

                  • [^] # Re: Merci, et une question

                    Posté par  . Évalué à 2.

                    Et leur critère est la perf par core, tu es sûr?
                    Je ne connais pas foule qui a ce critère dans notre monde qui passe de plus en plus au parallélisme (quand ça monte trop, pas mal de monde met un n-ième serveur en fait, en plus ça fait load balancing failover tout ça), plutôt accès sur le prix (qui comprend la surface, la perf/W etc).

                    Justement le HEP-Spec06 ne mesure pas la performance en parallélisme, chaque job se voit attribué un cœur et va tourner en monocoeur.
                    Ce n'est pas parce que le parallélisme est à la mode qu'il est adapté à toutes les situations. Si les expériences du CERN commence à utilisé des jobs multi-coeur, c'est surtout pour limité l'empreinte mémoire.

                    • [^] # Re: Merci, et une question

                      Posté par  . Évalué à 8.

                      Justement le HEP-Spec06 ne mesure pas la performance en parallélisme, chaque job se voit attribué un cœur et va tourner en monocoeur.

                      Tu veux dire que de l'Embarrassingly parallel n'est pas du calcul parallèle ? Et que HEP-Spec06 ne cherche pas justement à reproduire de l'embarrasingly parallel + un job scheduler avec sa métrique "parallel" ? :D

                      • [^] # Re: Merci, et une question

                        Posté par  . Évalué à 0.

                        Dans le définition même de l'"Embarrassingly parallel", les tâches n'ont pas ou très peu de dépendance entre elles, chaque tâche peu donc être exécutée indépendamment sur un cœur sans aucune interaction avec les autres, ce n'est pas du massivement parrallèle comme dans le HPC utilisé par exemple pour les prévisions météorologiques.

                        Maintenant, il commence à y avoir des jobs qui travaillent sur 8 coeurs en simultané mais ceci surtout pour économiser de la mémoire puisque des données identiques sont utilisées par les différents jobs (par exemple, les paramètres d'un détecteur).

                        • [^] # Re: Merci, et une question

                          Posté par  . Évalué à 5.

                          Mais personne ne dit le contraire et surtout pas le commentaire de zenitram auquel tu réponds initialement.

                          Tu veux absolument comprendre parallèle comme gros job communiquant a la MPI ou code multithreade alors que ce n'est qu'une façon très minoritaire de faire du parallelisme.

                          En 2015 la plupart des gens ont compris que multithreader était très compliqué, que de toute façon le scale out n'était pas loin et que la l'universal scalability law faisait très mal. Du coup on fait au maximum de l'embarassingly parralel, des architectures shared nothing etc.

                          Quand zenitram te dit "on rajoute un seuveur ça fait du failover et du LB" bin grosso modo c'est ça. Comme la plupart des archi web, big data, SOA etc. Ça scale majoritairement horizontalement quand c'est bien conçu (et quasi linéairement). Et oui rajouter une machine sur un cluster qui schedule des jobs EP mono thread rajoute du parallisme, tout comme rajouter un frontal HTTP derrière un LB).

                          Il ne faut pas voir le monde uniquement au travers du minuscule prisme du HPC.

                • [^] # Re: Merci, et une question

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

                  "On pourrait aussi parler de perf / m² et là le power8 surclasse certainement tous les autres…vu que sa performance par core explose tout."

                  Le P8 est un très gros coeur avec une énorme quantité de cache. A ce jeu-là, je pense que ARM serait imbattable. C'est l'origine de son succès pour les smartphones car la petites tailles garanti aussi une faible consommation.

                  "La première sécurité est la liberté"

              • [^] # Re: Merci, et une question

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

                Pour avoir écrit un gros bench, j'ai déjà fait ce genre de boulot.

                Il "suffit" de ne pas diviser par la fréquence. La normalisation détruisant de l'information. Le prix n'est pas du tout linéaire de la fréquence, donc je ne pense pas que cela soit une bonne raison.

                Un moyen de s'abstraire de la fréquence est de ne pas compter en instruction par seconde, mais en nombre d'instruction pour faire une tache. Pour une même architecture, avec des fréquences différentes, ce nombre est assez stable.

                " la perf par Watt, un autre critère, très intéressant "

                Oui, mais il compare en fait perf/watt/mhz.

                "La première sécurité est la liberté"

            • [^] # Re: Merci, et une question

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

              D'où l'intérêt de normaliser en fonction de la fréquence, justement. Ensuite ils peuvent sélectionner les chips en fonction des fréquences dispo, et voir où est le sweet spot pour eux (eg. en terme de perf/W/$).

        • [^] # Re: Merci, et une question

          Posté par  . Évalué à 10.

          Le HEP-Spec06 est un code de mesure de performances dans les sites HEP (Physique des Hautes Energies) et est représentatifs des calculs utilisés par les physiciens.
          Cette métrique est celle utilisés dans tous les centres relié au CERN et une mise à jour est à l'étude. Il faut savoir que jusqu'à l'année dernière, tous les calculs étaient mono-coeur, les jobs multi-coeurs ont fait leur apparition pour le redémarrage du LHC.

          Cela permet au centre de publier une puissance de calcul standardisée et d'optimiser les serveurs.

          Par exemple, dans notre centre, les derniers serveur mis en production sont équipés d'Intel E5 sandy-Bridge avec 12 coeurs physiques et donc 24 coeurs hyperthreadés.Le meilleur rapport HEP-Spec06 se situe lorsque l'on exécute 18 jobs simultanément et non 24, nous avons donc ouvert 18 "jobslots" par CPU.

          Le meilleur rapport qualité prix n'est pas forcément d'utiliser les CPU les plus puissant ou aillant le plus grand nombre de cœur car il faut affecté une quantité de mémoire à chaque "job" et le prix d'un serveur peu alors très vite augmenter.

          Voilà, je ne sais pas si j'ai été trés clair dans mes explications, mais c'est un peu compliquer à expliquer en quelques lignes.

          • [^] # Re: Merci, et une question

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

            L'explication est clair.

            "18 jobs simultanément et non 24, nous avons donc ouvert 18 "jobslots" par CPU."

            Cela parait logique à cause de l'usage de la bande passante mémoire et de l'augmentation des cache miss.

            "La première sécurité est la liberté"

    • [^] # Re: Merci, et une question

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

      Après, e ce que je vois du test : est-ce que le code produit n'est pas plus optimisé pour le x86 ? Car cela se base certes sur le même compilateur pour produire l'exécutable de chaque machine, mais nul doute que GCC a été fortement optimisé pour le x86 (plus de retours et contributeurs pour cette architecture).

      Je me demande sincèrement si ce biais existe, et quelle pourrait être son ordre de grandeur dans les résultats.

      • [^] # Re: Merci, et une question

        Posté par  . Évalué à 4.

        C'est une question très pertinente. Je pense que les architectures ARM sont suffisamment utilisées par des hackers pour que GCC ait un niveau d'optimisation raisonnable (sans parler du fait qu'une grande partie des transformations sont opérées dans le middle-end, qui se fout de l'archi cible). Par contre, pour le POWER8, si on n'utilise pas le compilo d'IBM, je ne sais pas à quel point GCC sait optimiser spécifiquement pour ce processeur (je suppose quand même que le « sous » jeu d'instruction PowerPC est correctement compris par gcc).

    • [^] # Re: Merci, et une question

      Posté par  . Évalué à 5.

      C'est comparé avec un E3, forcément max 4 cores.
      Mais les E7 peuvent avoir jusqu'à 15 cores. Donc 30 threads.
      Donc comparé à 32 threads (sur 8 cores!) du P8, en quoi le P8 a-t-il un avantage en densité?

      le power8 propose du SMT1, SMT2, SMT4 ou SMT8.

      Le serveur power8 non-IBM servant d'exemple n'a que 4 core d'activés donc 4 x 8 = 32

      Mais le power8 est un cpu 12 cores donc 12 x 8 = 96
      Ce genre de configuration est disponible chez IBM mais peut-être pas encore chez Tyan ou autre fournisseurs de mobo tiers.

      Donc le power8 n'a besoin que de 4 core pour proposer la même puissance qu'un E7. Et encore, la puissance par core d'un p8 est bien supérieure que celle de n'importe quel core intel (voir mon journal sur les bench openssl).

      Reste le problème de consommation d'énergie et le rapport perf/watt, qu'on peut éventuellement tolérer pour certaines charges de travail verticales.

    • [^] # Re: Merci, et une question

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

      Intéressant de voir qu'il y a quand même un gros problème d’intérêt (ne consomme pas moins, n'est pas plus puissant, alors que ça n'a pas l'air moins cher…) à part le "vendor lock-in"

      Je suis d'accord avec ta remarque, mais pour ceux, qui comme moi, sont moins à l'aise avec ce type de technologie j'aurais deux questions :

      1. IBM acte bien dans cette présentation que les processeurs P8 sont moins performants que les processeurs Intel Xeon ?
      2. Quelle est l'intérêt pour IBM de publier ce genre de résultat ?

      Parce que le « verrouillage propriétaire » (ma traduction spontanée de « vendor-lockin »), je trouve ça léger comme argument de vente (même si je reconnais son importance).

      • [^] # Re: Merci, et une question

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

        IBM acte bien (…)? Quelle est l'intérêt pour IBM de publier ce genre de résultat ?

        de ce que je comprend, IBM ne fait rien du tout, c'est une personne du CERN (un tiers aux vendeurs, ce qui rend l’intérêt encore plus grand) qui fait une comparaison.

        je trouve ça léger comme argument de vente (même si je reconnais son importance).

        Ben oui, des fois j'entends cet argument, mais voila : oui, c'est bien, mais pas suffisant! Il faut que ce soit au minimum aussi rentable.

    • [^] # Re: Merci, et une question

      Posté par  . Évalué à 5.

      Mais les E7 peuvent avoir jusqu'à 15 cores. Donc 30 threads.

      Même pas pas besoin d'aller taper dans les E7 qui sont assez rares. Un "simple" E5-2699 v3 dispose de 18 cœurs et un E5-2697 v3 de 14 cœurs.

      Le principal problème de ARM dans ce benchmark, c'est que ARM c'est assez nouveau sur le serveur et que c'est pas technologiquement à la pointe.

      Dans le test, le X-Gene 1 utilisé est gravé en 40 nm contre 22 nm pour le Xeon E3.

      Idéalement on aimerait plutôt comparer le Xeon E3 avec un Snapdragon 800 gravé en 28nm que l'on peut trouver dans les smartphones haut de gamme. Problème, il n'est pas disponible en plateforme "serveur", on se trouve donc à comparer les Xeon avec des procos ARM par terribles.

      Si on jette un œil au 7-Zip LZMA benchmark, on voit que sur ce bench, les processeurs ARM ont un bon ratio perf/W (qui dépasse souvent celui des proco Intel).

      Cela dit, je partage ta conclusion, pour l'instant sur les plateforme serveur, difficile de détroner Intel en termes de perf/W et perf/€.

  • # Question arch x86

    Posté par  . Évalué à 2.

    On ne parle plus que des Intel Xeon pour l'arch x86.

    Et les AMD Opteron, ils sont complètement "out" ?

    • [^] # Re: Question arch x86

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 avril 2015 à 18:56.

      Oui.
      AMD ne fait plus rien d’intéressant dans les CPU depuis des années, que ce soit grand public (et c'est un grand acheteur de CPU AMD à l'époque qui le dit, tout déçu qu'AMD n'est pas sû garder son avance technologique qu'il a eu à une époque) ou pro (ça n'a en fait jamais vraiment décollé)

      A noter qu'on ne parle plus non plus d'IA64, échec aussi (un bon gros échec, pas habituel chez Intel!)

      • [^] # Re: Question arch x86

        Posté par  . Évalué à 2.

        Côté grand public le plus puissant des AMD équivaut à un i5 moyenne gamme chez Intel tout en consommant plus.

        Par contre côté pro j'avoue ne pas savoir. En fait j'ai jamais vu d'Opteron sauf sur le VPS que je loue chez OVH. Mais toute ma vie je n'ai vu que du Xeon dans les datacenter…

        • [^] # Re: Question arch x86

          Posté par  . Évalué à 5.

          Des clusters d'Opteron c'était très très très courant a la fin des années 2000.

          C'était le moment ou leur rapport perf / prix étaient très bon comparé a de l'IA qui n'a jamais décollé et des xeons qui étaient plus cher pour pas mieux.

          Bon depuis… La dernière fois que j'en ai vu c'était il y a trois ans et c'etait un vieux rack de la grande époque qui avait été récupéré pour faire un cluster de test. Un musée quoi.

          • [^] # Re: Question arch x86

            Posté par  . Évalué à 2.

            HP continue à proposer des serveurs à base d'Opteron. C'est la série qui finie avec un 5 au lieu de 0 (ex: DL385 pour les AMD, DL380 pour les Intel).
            Pourquoi il continue, c'est la question. Peut être car ils ont une base client qui a miser sur la virtualisation sur plateforme AMD et que mixer AMD et Intel c'est pas terrible ? Pour faire un léger contre poids à Intel ?

          • [^] # Re: Question arch x86

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

            Titan (Cray XK7), c'est pas si vieux que ça (2012), mais ça doit par contre être le plus gros (et un des derniers) cluster à base d'AMD…

            https://en.wikipedia.org/wiki/Cray_XK7

            Proverbe Alien : Sauvez la terre ? Mangez des humains !

          • [^] # Re: Question arch x86

            Posté par  . Évalué à 3.

            Des clusters d'Opteron c'était très très très courant a la fin des années 2000.

            C'était le moment ou leur rapport perf / prix étaient très bon comparé a de l'IA qui n'a jamais décollé et des xeons qui étaient plus cher pour pas mieux.

            Surtout, les Opterons avaient l'HyperTransport, alors qu'Intel n'avait toujours pas produit de processeurs (IA64 ou x86) avec un réseau d'interconnexion efficace. Pour le cluster du CEA (à base d'IA64), Bull avait conçu et produit l'interconnect pour pouvoir faire communiquer 4 Itanium2 sur un même nœud à mémoire partagée.

      • [^] # Re: Question arch x86

        Posté par  (Mastodon) . Évalué à 6.

        IA64, échec aussi (un bon gros échec, pas habituel chez Intel!)

        Tu es peut-être trop jeune pour avoir connu ça : http://en.wikipedia.org/wiki/Intel_iAPX_432 mais dans le genre fail, c'est assez fortiche…

        • [^] # Re: Question arch x86

          Posté par  . Évalué à 2.

          Il y a aussi eu l'i860, qui était un « vrai » processeur RISC produit par Intel au milieu des années 90. Par contre je ne sais pas s'ils avaient décidé de produire ce processeur juste pour le calcul haute performance, ou bien s'ils avaient des ambitions plus larges.

          • [^] # Re: Question arch x86

            Posté par  (Mastodon) . Évalué à 2.

            Il y a aussi eu l'i860, qui était un « vrai » processeur RISC

            https://en.wikipedia.org/wiki/Intel_i860

            décidé de produire ce processeur juste pour le calcul haute performance,

            Je ne sais plus trop (ma vieillesse est un naufrage :) si c'est le 860 ou le 960, mais c'est un RISC qui a été assez apprécié dans les années 90 pour des applications très spécialisées de switching télécom, pour cause d'adéquation entre le jeu d'instruction, l'interface bus et les chips externes utilisés. Une vraie niche bien douillette, quoi.

            https://en.wikipedia.org/wiki/Intel_i960

            Si ça se trouve, je dois même avoir un peu de doc là-dessus dans mes archives papier, et le NDA est tombé depuis 20 ans :) Un dino pour nous rafraichir la mémoire ?

      • [^] # Re: Question arch x86

        Posté par  . Évalué à 4.

        Pas totalement vrai: certaines consoles de jeu "next-gen" sont équipées de processeurs AMD (notamment, PS4).

        Mais dans le monde entreprise et PC, c'est mort effectivement.

        • [^] # Re: Question arch x86

          Posté par  . Évalué à 2.

          Les deux plus grosses en fait (PS4, XBox One). C'est en fait très logique pour des consoles de jeu : avec les APU, on a de la mémoire partagée entre le GPU et le CPU, et tout est on-package/on-chip. Forcément, comme le matériel est fixe, ça veut dire qu'on peut produire des bibliothèques d'utilitaires pour les dévs de jeux qui tirent correctement parti de ce genre de technologie. C'est plus compliqué et moins évident pour ceux qui font de la programmation plus « générique ».

        • [^] # Re: Question arch x86

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

          Je pense surtout que AMD a été très agressif pour remporter le marché des consoles. AMD a quand même des difficultés financières importantes ces derniers temps, remporter un marché où il a la garantie de vendre une centaine de millions de puce sur 7-10 ans, même avec des marges très faibles ça permet à l'entreprise de tourner.

      • [^] # Re: Question arch x86

        Posté par  . Évalué à 6. Dernière modification le 15 avril 2015 à 14:22.

        A noter qu'on ne parle plus non plus d'IA64, échec aussi (un bon gros échec, pas habituel chez Intel!)

        Hum… comme HomeRF ? Comme le i960 ? Comme le WiMAX ? (OK dans ce dernier cas, c'est pas uniquement de la faute d'Intel, mais quand même un peu… :)

  • # Commentaire supprimé

    Posté par  . Évalué à -2.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Remarque concernant IA64 (Itanium), et autres puces 64 bits

    Posté par  . Évalué à 2.

    Je me permets d'ajouter ma vision du monde professionnel et des serveurs:
    - IA64 est certes moribond, mais pas encore complètement mort. A savoir que le seul constructeur à utiliser cette puce est HP, avec la gamme HPUX, en remplacement des puces PA-RISC.
    HP, après âpres négociations avec Intel, a forcé ce dernier à poursuivre le développement de la puce, et une nouvelle version en 22 ou 23nm va sortir bientôt.
    Et le monde HPUX est loin d'être mort, c'est d'ailleurs l'un des trois derniers Unix propriétaire utilisé, avec AIX et Solaris. Des sociétés comme Oracle continuent à produire des logiciels sur HPUX / Itanium.
    N'enterrons pas la puce tout de suite.

    • Concernant les autres "vraies" puces 64 bits encore vivantes (cad, avec la sortie de nouvelles applications), la liste est malheureusement courte: -- Oracle avec Sparc T5 et bientôt M7, -- IBM et son Power8 évoqué ici, -- et donc Itanium 2 de Intel.

    Ont ainsi disparu les magnifiques puces Alpha (DEC), et MIPS…

    • [^] # Re: Remarque concernant IA64 (Itanium), et autres puces 64 bits

      Posté par  . Évalué à 5.

      es sociétés comme Oracle continuent à produire des logiciels sur HPUX / Itanium.

      Parce qu'eux aussi le sont forcé http://www.zdnet.fr/actualites/oracle-reprend-le-support-logiciel-des-processeurs-itanium-39782239.htm

      Au final, il a fallu forcé le développeur du processeur et les développeurs d'applications pour continuer le développement du support, ça n'augure pas vraiment un avenir radieux.

      ne nouvelle version en 22 ou 23nm va sortir bientôt.

      Tu as des sources là dessus, parce que je n'ai vu parlé que de Kittson en 32nm (même si initialement prévu en 22nm). Sinon, il semblerait que HP ne paye pour du développement jusqu'en 2017 et commence

      Sinon, si j'ai bien compris la gamme HP, le successeur des serveurs à base d'Itanium est le Superdome X qui est basé sur du Xeon. http://www8.hp.com/be/fr/products/integrity-servers/product-detail.html?oid=7161269#!tab=specs

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Remarque concernant IA64 (Itanium), et autres puces 64 bits

      Posté par  . Évalué à 2.

      comme cela a été dit les prochains gros serveurs hp tourneront sur xeon.

      quant au sparc il n'est plus pris en charge sous debian et donc Ubuntu par voie de consequence (bon j'ai pas été vérifier j'ai la flemme) cela prive donc d'une grande communauté d'utilisateurs. de toute façon oracle pousse à fond ses appliances type exdata sous linux x86…

      bref selon moi il n'y a que le Power qui puisse avoir un avenir car :

      1) marché legacy

      AIX / as400
      qu'on le veuille ou non il y a un existant conséquent qu'il faut rafraîchir régulièrement

      c'est hautement virtualisé et dispose de tous les trucs modernes fashion type api rest, open stack avec powervc etc…

      2) investissements lourd de linux sur power

      support little endian pour faciliter les portages

      portage de kvm

      3) ouverture de l'architecture

      rendant possible existence de serveurs non ibm

      nombreux contributeurs et partenariat openpower

      4) power9 et nvdia

      ibm a remporté le marché visant à remplacer des supercalculateurs

      une interconnexion nvlink est créé entre le power9 et les gpu (je vous laisse chercher)

      tout ceci est donc gage de pérennité

      gage de pérennité car si le power survit Aix aussi et tout le reste

    • [^] # Re: Remarque concernant IA64 (Itanium), et autres puces 64 bits

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

      A savoir que le seul constructeur à utiliser cette puce est HP, avec la gamme HPUX,

      Je me permets de rebondir : tu oublies OpenVMS, dont HP a refile le développement à VSI
      http://vmssoftware.com/
      et qui annonce une nouvelle version 8.4-1H1, et aussi le portage d'OpenVMS sur X86 (sous 3 ans en théorie)

      ウィズコロナ

Suivre le flux des commentaires

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