Google est sûrement l’une des entreprises disposant du plus grand parc de serveur au monde. Même si Google ne précise pas les chiffres et les caractéristiques techniques de ses serveurs, on se doute qu’ils tournent tous, ou presque, avec un processeur Intel. En effet, le géant de Santa Clara domine largement le marché du serveur avec une part de marché qui atteint… 99 % contre 80 % sur le marché du PC classique. Son grand rival d’antan, AMD, a totalement perdu la bataille des serveurs, mais un troisième acteur très connu dans le monde du mobile pourrait bien faire sa grande apparition cette année.
24 cœurs ARM pour Google
Selon les sources du site Bloomberg, Qualcomm aurait signé un contrat avec Google afin de livrer au géant de Mountain View des processeurs Snapdragon à destination des serveurs. Il pourrait alors s’agir de la puce annoncée en octobre dernier par Qualcomm, intégrant 24 cœurs ARMv8 gravés en 16 nm et disponibles en socket pour les intégrer sur les cartes mères. En signant un accord avec Google, Qualcomm s’assure un marché très important et pourrait bien faire de l’œil à d’autres entreprises qui raffolent des serveurs comme Microsoft ou Apple. Google achèterait chaque trimestre 300 000 processeurs pour ses serveurs, ce qui représenterait actuellement 5 % de la totalité des serveurs du monde.
Qualcomm vs Intel
Pour le moment, le marché des serveurs non x86 RISC (comme les puces ARM) représentent environ 20 % en valeur contre 80 % pour les puces x86. L’arrivée de Qualcomm chez Google pourrait donc faire bouger les choses, et remettre en cause la position ultra dominante d’Intel sur ce marché. Les puces ARM sont moins puissantes que les processeurs d’Intel mais bénéficient d’une consommation largement inférieure, ce que recherchent désormais principalement les donneurs d’ordre, notamment pour le cloud. Intel qui est malmené sur le marché des puces mobiles, notamment par Qualcomm, risque bien de se faire chahuter également par le géant de San Diego sur le marché des serveurs.
Pour ne rater aucun bon plan, rejoignez notre nouveau channel WhatsApp Frandroid Bons Plans, garanti sans spam !
Il y a l'architecture, la micro architecture, le procédé de fabrication et le compilateur. Ce qui rend l'architecture Intel moins efficace que les RISC en général, c'est qu'il faut une unité de décodage des instructions CISC vers RISC plus importante (le coeur des Intel, c'est du RISC). Ce qui rend l'architecture ARM plus efficace que les autres l'architectures RISC, c'est le fait de faire des SoC sur mesure, le fait qu'il n'y a pas d'instructions "juste pour les perfo", comme sur certains autres RISC (je pense à l'architecture SPARC et son cache prefetch exclusif, les register window qui servent plus où moins à rien, je connais pas powervr et MIPS...). Mes connaissances remonte à longtemps, mais les choses n'ont pas trop changé.
Oui, c'est juste une accusation et pas un verdict d'un jugement. Vu le poids des Samsung, Mediatek, Hisilicon ou encore Allwiner alors cette accusation me fait pouffer et ne m'inquiète pas le moindre du monde.
Avec le 14nm, l'avance d'Intel a fondue. Il a même son Atom x3 qui est en 28nm, ok ce n'est pas lui qui le fabrique, mais ça fait tâche chez celui qui a donné l'habitude d'être largement en avance sur les autres. Commercialement, il va lui falloir + qu'une petite avance s'il veut faire résister son x86...
Qualcomm est accusé d'abus de position dominante.
??? Pendant un temps, Intel tenait les uns par les couilles et écrasait les autres. Qualcomm est très loin de pouvoir se le permettre. Et il n'y a jamais eu autant d'acteurs d'envergure différents. Pas vu ces enquêtes, elles sont où ?
En effet, là où certaines archis dont ARM avait beaucoup de marge d'évolution, elles le comblent. Intel n'a pas cette chance... mais il a toujours eu un cran d'avance en finesse de gravure (oui les fondeurs d'ARM aussi, TMSC y arrive presque, etc..) mais ce petit cran vérifie bien la loi de pollack à l'avantage d'intel... pis bon, demain on trouvera encore autre chose à dire, mais on arrive à l'état de l'art, qu'importe le côté qu'on se trouve... Nikonistes, Canonistes alike, c'est pas habitude qu'on choisi, pardon, on reste, dans son camp, par confort, ou parce que j'ai besoin d'une feature de calcul vectoriel que je trouve pas ailleurs... Perso, je pense sincèrement, aujourd'hui (j'ai été un ultra pourfendeur des alternatives) que les deux se valent. Le monde ARM aura l'avantage d'offrir des SoC si variés que chacun trouvera celui qui ira bien pour son appli, sans trop dépenser... Et pour les charges hétéroclytes, x86 sera toujours là pour dire présent... Faut juste espérer qu'Intel arrête d'être pingre à réserver l'AES-NI à certaines gammes, salauds !
Les enquetes sur Qualcomm disent le contraire...
Depuis 2014, les ARM se sont améliorés en gravure mais surtout en débit mémoire. Ces améliorations on environ doublé les perfs dans certains tests (ce qui en met au niveau des premiers i3 (qui consomment + que les ARM), du jamais vu) tout en contenant la conso. Les x86 pendant ce temps on paraît-il peu augmenté en perfs. Ils ont gagné en conso, mais a-t-elle été divisé par 2 ?
T'as raison, j'avais zappé, cela-dit, ils en sont toujours au Piledriver sur les gros Opteron à 12/16 pseudo-cores (dual die à chaque fois, tricheurs :) ) (pas la série X, limité au quad Jaguar) Correction: t'es sur que c'est pas des Jaguar dans la PS4 ? en dual die c'est le premier capable de totaliser 8 coeurs... faire du octo-bobcat, bon courage
Il y a pas AMD qui veut revenir aussi sur le domaine du pro' avec de nouveaux opteron basé sur leur nouvelle architecture Zen ? -c'est une question, j'affirme rien...-
scaler bobcat ne devrait pas causer problème puisque la PS4 et la xbox one ont tout les deux un SoC avec 8 bobcat. L'article que tu as envoyé est intéressant, merci pour le lien ;)
Parce qu'ils savent pas scaler du Bobcat ? Par effet de mode ? Parce que ça correspondrait bien a certains types de payloads spécialisé ? (Moi je craque perso :-) ) Tiens, j'avais trouvé des résultats brutes mais y'en a qui ont fait de beaux graphiques avec des couleurs en résumant bien ma pensée : http://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient/2 J'ai perdu mon dernier Hennessy&Patterson, mais c'est un bon bouquin à lire sur les architectures de CPU
Si un cœur Bobcat est aussi efficace voir plus qu'un A15, pourquoi AMD a lancé des opterons avec 8 A57 ?
On en aurait causé y'a 10 ans en arrière c'était une autre histoire... Mais dans les deux camps, hormis les mauvaises implémentation de MIPS, tous ont fait d'énormes progrès et sont devenus extrèmement proche... Et on peut trouver pratiquement tous les payloads qu'on veut, même un coeur Bobcat est aussi efficace vois plus efficace qu'un A15, surtout si l'on les pondère à l'énergie utilisé. Le débat n'a plus lieu d'être de nos jours, la différence se fait en périphérie du CPU
Si arm eux même n'utilise pas les bons termes ... Si ARMv8 était une architecture, pourquoi les cortex A5x existerait ? On aurait directement des cœurs ARMv8 si c'était une architecture.
Les Crusoe/Efficeon permettait même de changer toute la couche d'abstraction... J'aurai toujours kiffer m'acheter un OQO rien que pour ça (et à l'époque, ce truc était particulièrement classe)
Une archi CISC optimisé à fond consommera toujours plus qu'une archi RISC optimisé à fond car les archi CISC ont besoin de plus de transistor pour traiter les instructions. Les archi CISC ont eu du succès car plus simple à coder en assembleur. à l'heure actuelle où nous avons des compilateurs très efficace (et que donc presque plus personne ne code en assembleur) ce n'est plus un critère de choix, ce qui a fait en partie le succès d'ARM. Après oui si tu compare au processeur de la PS3 ou celui de la XBox 360 ce sont clairement pas des bons exemples.
Ce n'était pas forcément le coeur de métier, sans jeu de mots... Mais oui, mettre du ARM hard dans un FPGA, c'est assez à la mode... De toute manière, comme pratiquement tout le monde a une license ARM et en fait un peu, quiconque rachète un autre va forcément en avoir en plus...
Dans l'héritage Motorola, si tu parles de 68k, c'était du CISC, mais, l'ex sous branche Freescale ayant pris ses ailes a aussi bossé sur les PowerPC avec IBM... (j'ai d'ailleurs un P2020 qui tourne). Depuis ils pondent beaucoup de soc à base d'ARM, j'ai une palanqué d'iMX6 très différents d'ailleurs... (A noter, Freescale n'est plus, en cours de digestion par NXP)
http://www.arm.com/products/processors/armv8-architecture.php <- pas une architecture?
Le SPARC M7 peut exécuter 256 threads. Difficile de lui en vouloir s'il consomme + qu'un x86 à 16 threads.
Il y a les Power d'IBM, les SPARC, les MIPS, peut-être des héritiers des Motorola chez Freescale...
Pas vraiment. Le x86 c'est quasi que Intel qui se comporte en macro et se permet de faire 63% de marge !!! Pour ce qui est des ARM, il y'a une vraie concurrence de concepteurs, fondeurs et d'OS. C'est très différent.
Tous leurs smartphones sont en ARM. Microsoft fait parti des très nombreux à avoir acheté de la licence ARM.
Microsoft fait parti des contributeurs pour l'Open Source (dont des choses pour Linux) et pas des moindres.
Windows tourne déjà sur ARM dans les Windows Phone.
La nouvelle informatique grand public se tourne vers les pico ordi, dont le + connu et un des moins cher est le Raspberry PI. Mais surtout, ce qui est promis à une très large adoption c'est son smartphone qui se transforme en utilisation ordi quand il est connecté à un grand écran.
i960 Intel a racheté Altera qui fait des puces avec des coeurs ARM.
Le software, Google connaît bien. Les ARM, Google bien. Google fabrique ses serveurs et ses software depuis bien longtemps, et a les moyens de faire le changement sans problèmes. Qualcomm n'est pas le seul concepteur d'ARM pour serveurs. Il y a TI et AppliedMicro qui sont dans des Moonshot de HP. Il y a du Cavium à 48 coeurs, et aussi du AMD, Freescale, Hisilicon, et AnnapurnaLabs qui à récemment été acheté par Amazon. Online, qui fait parti du même groupe que Free, a des serveurs en ARM.
Les coeurs des Intel sont en RISC, avec du micro-code pour convertir les instructions x86 en RISC. Cette phase est une pénalité de + de 10%.
J'ajoute... on peut pas dire que l'un consomme moins qu'un autre... L'avantage des Arm (et non Risc vs Cisc) est qu'on gagne bcp de features jusque là rares, qu'ils sont facilement scalables (un fondeur veut monter un 64 cores? Bah il le fait... pas besoin d'attendre sur le fabricant) et Arm permets l'hétérogénéité aussi... et dans des applis sollicités par a coups j'y vois un gros intérêt
Attention... on peut dire qu'Arm force a l'efficacité... mais on ne peux pas dire que le Risc est moins énergivore que Cisc... je peux pondre une list de Cpu Risc qui consomment trois fois un PC de gamer seuls... A l'inverse Intel, et de manière surprenante Amd aussi, ont fait d'énormes progrès sur leurs cores et n'ont plus beaucoup à rougir face a certains SoC Arm... Quand on vois du Arm et du x86 se battre à des tdp de 2w pour des prestas proches, je vois déjà certains de mes projets utiliser des intel x5 à la place de certains SoC mal documentés
? C'est pour moi la réponse, je comprends pas... Sinon oui... les AS400, c'est du Power d'IBM (grand cousin du PowerPC) Je maudis la plateforme, faite par et pour des masochistes... mais je dois avouer que c'est béton... une fois que l'ingénieur à 800€ de tjm fini par peaufinner ses scripts pour éviter les plantages le weekend a cause du brms
La quasi totalité du codebase est portable et porté, pendant longtemps, il y a eu des versions Sparc, Mips, Alpha (<3), s390, PowerPC des Windows NT... dont le noyau existe dans les actuelles... d'ailleurs Windows RT trouvé sur les tablettes crosoft bah... c'est bien pour du Arm... Windows sur Arm est une réalité, de plus en plus et pour longtemps
Encore du Qualcomm! Alors qu'il y a des concepteurs spécialisés dans les puces pour serveurs avec plus d'expérience! Qu'on ne me dise pas que Google ne favorise pas Qualcomm !
Lis l'article que j'ai ajouté il y a qques minutes.
Ta '' source '' wiki ne montre pas qu'un x86 est un RISC. Bien sûr que tous les CISC peuvent être substitué à des RISC c'est le principe même, sauf que faire une instruction du registre '' CISC '' sur un RISC prendra 10 à 15 fois plus de tick horloge. C'est comme dire que tu peux faire une multiplication avec des addition :) Bref, x86 est toujours un CISC :)
Oh les sources il y en a bcp en cherchant 'x86 risc cisc' sur google, tu verras que la question est compliquée en fait. Mais une facile c'est la dernière phrase du chapitre Histoire par exemple de la page RISC : https://fr.wikipedia.org/wiki/Reduced_instruction_set_computer#Histoire C'est compliqué parce que : - il n'y a pas de définition ferme et définitive de l'un et de l'autre (on m'a même expliqué que la traduction de RISC est "ordinateur à jeu d'instruction réduites" et pas "ordinateur à jeu réduit d'instructions", la nuance est vachement importante !!!) - le x86 a bcp évolué dans son histoire Mais un CPU moderne, c'est bien un RISC, avec ensuite du microcode pour avoir accès à des instructions plus complexes. Et sinon Houdini a prouvé que exécuter du ARM par un x86 c'est pas très dur, il y a une translation quasi immédiate des instructions (tu pourrais presque écrire un traducteur qui trouve une instruction x86 pour chaque instruction ARM). Donc c'est pas si loin en fait.
Hum ok... J'ai du mal à considérer x86 comme RISC vu le nombre d'instruction disponible par rapport à de l'ARM... En tout cas tout ce qu'on trouve sur internet, en rien x86 se rapproche d'ARM... Après si t'as une source je suis preneur :)
Alors CISC vs RISC est un sacré débat (tout le monde pioche maintenant dans ces 2 architectures), mais bcp considèrent la quasi totalité des CPU modernes comme RISC, y compris les x86. Mais préciser "RISC" n'a que peu d'intérêt en fait.
Mettre fin à une hegemonie pour enb creer une autre
À une époque, hotmail fonctionnait sous FreeBSD. Je suppose que ms à encore quelques serveurs bsd
ArmV8 = jeu d'instruction et non architecture de cœur Les cœurs de l'apple A7 sont compatible ArmV8. Ceux de l'A8 aussi, ceux de l'A9 aussi, les cortex A53 aussi, les cortex A57 aussi, les cortex A72 aussi. Les cœurs compatible ARM ont tendances à moins chauffer que les cœurs compatibles x86 car ARM est un jeu d'instruction simple (RISC) alors que x86 est complexe (CISC).
Microsoft a déjà une version de windows qui tourne sur Raspberry(certes très légère). Ils doivent un peu connaître les archis ARM quand même.
je trouve la phrase "le marché des serveurs non x86 RISC" assez bizarre. * Non x86 (CISC) * RISC * Non CISC Enfin il manque un truc je pense, parce x86 RISC connais pas :P
Vu les investissements que fait Microsoft sur la para-virtualisation sous Linux, j'ai comme un doute ;-)
Sauf que ms a complètement perdu le marché des serveurs. La majorité sont sous linux ou BSD, qui sont open source, et déjà compilé pour du arm
Une bonne nouvelle pour la planète et pour nous. Si les ARMs se développent autant dans les smartphones et en // dans les serveurs, il ne faudra pas longtemps pour en disposer également dans nos ordinateurs, qui consommeront moins et chaufferont moins.
En masse, plus trop, hormis quelques chips spécialisés... Mais il fût un temps où Intel en faisaient des caisse, ce dernier possède depuis des plombes une license ARM... On se souviendra longtemps de la famille des StrongARM, racheté à Digital, devenu les XScale, puis revendu à Marvell, et qui existent toujours dans la famille Armada... Que de souvenirs de son iPaq de Compaq/HP, sous Qtopia/Angstrom
<blockquote>En effet, le géant de Santa Clara domine largement le marché du serveur avec une part de marché qui atteint… 99 % contre 80 % sur le marché du PC classique.</blockquote> <blockquote>Pour le moment, le marché des serveurs non x86 RISC (comme les puces ARM) représentent environ 20 % en valeur contre 80 % pour les puces x86.</blockquote> Intel fait du non-x86 ?
Il faut pas "tout refaire". Une bonne partie de ce qui est utilisé aujourd'hui par les géants du web est une partie en open-source (nginx etc) sur une base Linux, le tout tournant parfaitement sur de l'ARMv8. Le reste est interprété, et tournera tout pareil, une fois que l'interpréteur tourne (ce qui est déjà le cas pour la très grosse majorité des technos utilisées).
Bien au contraire, c'est pas le PC à Mamie dont on parle, la gestion de la chaleur est un aspect très important et qui doit coûter cher à Google. Bon sinon c'était une tite blague de Virtual Glitch, Google compte pas installer des Snapdragon 810, si les proc serveur de Qualcomm consomment moins, ils dégagent certainement également moins de chaleur.
Dans un datacenter,tu as un.refroidissement par eau glacée et ça coite cher. Pour moi,Google utilise Qualcomm pour négocier avec Intel, une baisse des prix. Derrière,il faut tout refaire niveau software et tout remettre en arm. C'est un coup de bluff.<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>
Dans un serveur aucun problème il y a des ventilos et de l'espace( en tout cas, bien plus que dans un smartphone)
Alors qu'ils installent de très bons systèmes de refroidissement. ;)
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix