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 reynum (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)
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 Zenitram (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 :
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 Nicolas Boulay (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 lasher . Évalué à 3.
C'est mon problème avec ce benchmark:
Bref, j'aimerais avoir quelqu'un qui m'explique un peu comment lire les graphes.
[^] # Re: Merci, et une question
Posté par Benoît Ganne (site web personnel) . Évalué à 3.
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.
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 Antoine . Évalué à 4.
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 Benoît Ganne (site web personnel) . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 Zenitram (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 Dabowl_75 . É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 Zenitram (site web personnel) . Évalué à 0.
Tu peux le garantir?
Ca dépend des Watts consommés aussi à ma connaissance (problème de dissipation)
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).
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 Dabowl_75 . Évalué à 2.
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 :-)
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 seraf1 . Évalué à 2.
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 ckyl . Évalué à 8.
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 seraf1 . É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 ckyl . É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 Nicolas Boulay (site web personnel) . Évalué à 4.
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 Nicolas Boulay (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.
Oui, mais il compare en fait perf/watt/mhz.
"La première sécurité est la liberté"
[^] # Re: Merci, et une question
Posté par Benoît Ganne (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 seraf1 . É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 Nicolas Boulay (site web personnel) . Évalué à 4.
L'explication est clair.
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 Renault (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 lasher . É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 Dabowl_75 . Évalué à 5.
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 vlamy (site web personnel) . Évalué à 1.
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 :
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 Zenitram (site web personnel) . Évalué à 6.
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.
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 X345 . Évalué à 5.
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 dpascal . É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 Zenitram (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 MTux . É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 ckyl . É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 Julien L. . É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 Loïs Taulelle ࿋ (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 lasher . Évalué à 3.
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 Tonton Th (site web personnel, Mastodon) . Évalué à 6.
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 lasher . É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 Tonton Th (site web personnel, Mastodon) . Évalué à 2.
https://en.wikipedia.org/wiki/Intel_i860
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 Loïs Taulelle ࿋ (site web personnel) . Évalué à 1.
Tu pense au Paragon ? (https://en.wikipedia.org/wiki/Intel_Paragon, base i860)
Sinon y'a eu une gamme de carte RAID qui étaient basées sur du i960… (MegaRAID, au moins)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Question arch x86
Posté par georgeswwbush . É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 lasher . É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 Renault (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 karteum59 . Évalué à 6. Dernière modification le 15 avril 2015 à 14:22.
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 Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Propale de correction/diff
Posté par vlamy (site web personnel) . Évalué à 5. Dernière modification le 15 avril 2015 à 14:26.
T'aurais dû « forker » le site et faire une « pull request », ça aurait été mieux reçu j'ai l'impression.
[^] # Re: Propale de correction/diff
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Remarque concernant IA64 (Itanium), et autres puces 64 bits
Posté par georgeswwbush . É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.
Ont ainsi disparu les magnifiques puces Alpha (DEC), et MIPS…
[^] # Re: Remarque concernant IA64 (Itanium), et autres puces 64 bits
Posté par claudex . Évalué à 5.
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.
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 Dabowl_75 . É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 palm123 (site web personnel) . Évalué à 3.
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.