Aujourd'hui, Intel est quasiment le seul maitre à bord sur le segment des serveurs pour moyennes et grosses entreprises. Les processeurs Alpha, SPARC et autres ont été balayés via un marketing efficace mais aussi des supports de gros éditeurs tel que Microsoft.
IBM ne souhaite pas pour autant jeter l'éponge et propose aux entreprises des serveurs à base de processeurs Power8.
Jusqu'il y a peu, seule Ubuntu supportait cette architecture. MAis bien qu'Ubuntu soit populaire chez les particuliers et quelques vendeurs de Cloud, cette distribution reste très en retrait dans le monde des entreprises. Ci-dessous un article très intéressant sur le sujet :
SUSE vient maintenant de rentrer dans la danse et affirme que SLES 12 (qui sortira d'ici peu) supportera le Power8 d'IBM, avec même l'aide de MariaDB
Est-ce que la technologe Power pourra trouver sa place dans un monde dominé par Intel ? Nils Brauckmann (SUSE) affirme que le CA SUSE sur Power a gonflé de 60% en un an. Chiffre impressionnant à condition que celui-ci ne parte pas de presque rien.
A noter que Redhat, le leader Linux, reste absent de ce segment. Cela ne devrait cependant pas durer : SUSE avait été un moment seule sur le monde du Mainframe Linux avant que Redhat ne sorte sa version. Il en fut de même pour SAP Hana. Redhat pourrait se sentir obligée d'agir, car certains clients restent réticents à adopter du SUSE (car pour de grands groupe, toute une baterie de certification est nécessaire avant d'implémenter un OS, que ce soit au niveau des sauvegardes, monitoring, relances… Redhat est généralement déjà certifié pour ces gros clients).
Wait and See…
# Une première !
Posté par Philip Marlowe . Évalué à -2. Dernière modification le 07 octobre 2014 à 22:55.
Samuel cite nommément Red Hat !
Edit : et d'autres…
[^] # Re: Une première !
Posté par Maclag . Évalué à -4.
Oui, et pour dire que RedHat sont les leaders… qui suivent tout ce que fait Suse!
Fallait pas en demander trop non plus…
[^] # Re: Une première !
Posté par dinomasque . Évalué à 10.
Oh mon dieu ! quelqu'un publie des journaux bien écrits, informatiques et en plein dans le sujet (Linux et les logiciels libres) !
C'est vraiment scandaleux, vous avez raison de rouspéter.
BeOS le faisait il y a 20 ans !
[^] # Re: Une première !
Posté par freem . Évalué à 10.
Laisses tomber, certains sont tellement aveuglés par les noms et les réputations qu'ils en oublient les contenus pertinents.
[^] # Re: Une première !
Posté par Philip Marlowe . Évalué à 3.
J'admire ta capacité de lire ce que je n'ai pas écrit. Je faisais remarquer un caractère réellement nouveau de ce journal, en l'occurrence excellent, de Samuel Pajilewski, celui de citer d'autres distributions que celles qu'il a en prédilection.
En aucune manière il était possible de trouver un quelconque dénigrement dans ma remarque. Un commentaire de pure frivolité. Une remarque sans importance. C'est stérile de répliquer à une remarque sans importance, aussi te fais-je l'honneur de faire la même chose avec le tien et ajouté-je un caractère récursif au présent mien. J'espère que tu seras content du cadeau.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Non !
Posté par lasher . Évalué à 10.
Bon en fait quand même, c'est un peu plus compliqué que ça. Le POWER8 est un processeur « high-end » : il n'est destiné qu'à de gros serveurs, car c'est une puce qui chauffe beaucoup (comme ses grandes sœurs). D'après cette présentation, IBM réutilise le SMT ce qui leur permet de clamer une capacité de « 8 dispatch » par cœur. Si en plus on rajoute la mémoire transactionnelle gérée en hard (depuis le POWER7 je crois bien), comme maintenant les mémoires transactionnelles sont gérées dans
gcc, si jamais le code en tire parti, il y a de fortes possibilités d'accélération dans les codes parallèles et concurrents (si les régions critiques protégées par les mémoires transactionnelles ne présentent pas trop de contention, alors les programmes multithreadés tourneront à plein pot.Sérieusement, ce processeur est une Ferrari à bien des égards, et si la charge est réellement importante, ça peut parfaitement être justifié : 6 à 12 cœurs par processeur, 8 threads hardware par cœur, ça fait presque 100 threads sur le processeur, ce qui est pas mal du tout, si la charge de travail s'y prête !
… Par contre, c'est pas donné : c'est comme n'importe quel truc très haut de gamme, il faut acheter le tout : processeur, mais aussi RAM, stockage, réseau, etc., sinon ça ne sert pas à grand chose. Il y a pas mal de machines pour la haute-performance qui utilisent ce genre de choses, car généralement ces processeurs sont plutôt très fiables.
[^] # Re: Non !
Posté par Christophe B. (site web personnel) . Évalué à 6.
+1
Pour avoir proposé du power à mes clients il y a quelques années, l'obstacle c'est le prix.
Sinon coté performance, maintenabilité, service, fiabilité et durée de vie : ya pas mieux.
Faut en avoir besoin, si tu as des base de données de plus de 1 To et que tu as environ 3000 utilisateurs de par le monde qui ne penses qu'à lire et écrire dedans.
il vaut mieux avoir du power :)
Même si les serveurs en tant que tel sont chers, après les logiciels qui vont dessus sont généralement hors de prix, le cout du service est aussi pas donné car il s'agit de gens certifié etc …
C'est un peu comme Apple, c'est très cher mais tu en as pour ton pognon.
[^] # Re: Non !
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
C'est vraiment vrai ça ?
A combien arrive une config PC multisocket >256Go de RAM, et des SSD pro voir même des SSD sur port PCI ? 20k€? Combien l'équivalent sur ibm ?
Tu veux dire pas comme Apple, non ?
"La première sécurité est la liberté"
[^] # Re: Non !
Posté par Christophe B. (site web personnel) . Évalué à 4.
Oui c'est un cas authentique, et c'est la plus grosse config que j'ai rencontré.
Il n'y avait jamais 3000 utilisateurs en même temps mais cela plutôt tournait autour de 1000 avec des pointes a 1500 quand les gros pays se mettaient à bosser.
D'abord c'était il y a 4 ou 5 ans, on ne parlait pas encore de SSD et le but primordial recherché était la redondance sur 2 sites, la capacité qu'ont certaine architecture de remplacement de tout à chaud etc …. et surtout la garantie que cela ne va pas tomber en panne (ou presque) … chaque arrêt coûte très cher. Ensuite il y a l'historique.
c'est la bas que j'ai pu appréhender 2 trucs monstrueux (enfin pour moi)
les baies XIV (ixe-aille-vie pas quatorze :) ) je sais qu'il y avait 3 baies 1 pour les sauvegardes, les 2 autres pour les données.
C'est le genre de truc qui se débrouille tout seul et qui s'optimize tout seul ya rien a faire si ce n'est de dire combien tu veux de volume et qui à qui tu les attaches.
la sauvegarde en continu avec l'émulation de dizaines (je sais plus si c'est 64 ou 128) Drives LTO et réplication en continu. Il y a avait constamment de 8 à 10 "drives" en cours d'utilisation. Chaque jour plusieurs To se sauvegardait avec un total de 100 To.
Pour infos on m'avait attribué une partition (équivalent VM) sur les serveurs de tests pour faire du shell scripts : 4 Processeurs / 64 Go de RAM / 100 Go de disques à la fin comme j'avais du tester le stripping sous on m'avait accordé quasiment un To de disques
C'est peut être petit pour certain, mais a voir tourner c'est impressionnant (enfin pour moi)
Et cela me rappelles le temps (oui les moins de vingt ans l'ont pas connu) ou je gérais une douzaine de serveurs unix et sur comp.os.unix on échangeait (comme ici d'ailleurs) mais bon certains avait la responsabilité de plus de 1500 serveurs sous AIX.
[^] # Re: Non !
Posté par Dabowl_75 . Évalué à 3.
Le POWER8 est un processeur « high-end » : il n'est destiné qu'à de gros serveurs
non, il y a des serveurs P8 d'entrées de gamme à des tarifs tout à fait compétitifs.
S814, S824…mono ou dual socket, dans lesquels on peut mettre beaucoup de RAM.
Il y a mêmes des modèles Linux Power only, comme pour la gamme P7 précédente.
Donc ce n'est pas destiné qu'à de gros serveurs CQFD
[^] # Re: Non !
Posté par Prosper . Évalué à 5.
Qu'appelles tu compétitif ? quel fourchette de prix ?
[^] # Re: Non !
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
Je crois surtout que c'est un problème de commercialisation. Les plate-formes qui fonctionnent sont supportées par beaucoup de constructeurs ce qui ne rend pas le client trop dépendant d'un seul fournisseur. Si beaucoup de boites se sont éloignés du sparc / solaris ou des gros systèmes IBM, c'est juste qu'elles en avait marre de se faire racketter sur la maintenance.
Par exemple cet article expliquait comment la migration cobol / mainframe vers java / intel avait fait économiser 3 million d'euros en maintenance informatique à une boite.
La question est donc de savoir si IBM est prêt à ouvrir sa plate-forme au constructeur ? Va-t-on trouver du power8 chez DELL, HP, SuperMicro, Tyan … Et si les constructeurs vons en avoir envie … Visiblement un effort dans ce sens est fait avec la fondation OpenPOWER qui planche sur des spécifications notamment une carte mère de référence.
Ce genre de choses ont déjà été faites. Sans forcément beaucoup de succès. Toutefois, il semble que cette fois IBM ait levé un bon gros lièvre qui a la capacité de faire bouger les lignes.
[^] # Re: Non !
Posté par freem . Évalué à 1.
Tout est dit. Peut-on vraiment comparer les mainframe avec power? Du (très) peu que j'en sais, les anciens mainframes pour aussi performants qu'ils soient, ne peuvent être ciblés par beaucoup de langages, ce qui est un problème.
Sur power, si Ubuntu supporte, ça veut dire linux, et si Ubuntu marche, c'est probablement grâce au travail de Debian, qui à une quantité non négligeables de paquets, incluant Java, python et C/C++. Entres autres.
Du coup, le coût de développement logiciel devrait être moins élevé que pour du cobol, je suppose? Tu l'as dit après tout: pas mal de choses ont été portées sur Java…
'fin bon, vue ma compréhension du sujet (big data & co, je ne connais malheureusement pas), je ne dis peut-être que de la merde.
[^] # Re: Non !
Posté par palm123 (site web personnel) . Évalué à 8. Dernière modification le 08 octobre 2014 à 11:39.
Un avis venant d'une personne qui a vécu des migrations OpenVMS de Vax vers Alpha et d'Alpha vers Itanium : non.
Il faut que toutes les boites de soft (qui proposent cet OS sur cette architecture) "supportent" ce Power8, et donc portent/proposent leur produits (bases de données, applis utilisant une base de données, soft faisant du ciblage moléculaire ou autre chose…).
Cela a un coût, et évidemment les boites ne le feront que si elles voient un retour sur investissement rapide.
Ce Power8 est dédié aux gros projets, et par définition, il y en a peu.
Donc l'immobilisme est le meilleur allié d'Intel.
Si les qualités techniques suffisaient à imposer un produit…
ウィズコロナ
[^] # Re: Non !
Posté par Dabowl_75 . Évalué à 1.
Le power8 ne s'adresse pas qu'au marché "legacy" mais vise aussi les charge de travail dites cloud/big.data/analytics/
[^] # Re: Non !
Posté par lasher . Évalué à 4.
Il y a une grosse différence avec l'Itanium : ce dernier était génial pour du calcul flottant, et pourri pour de l'entier. Si ton appli se repose sur un systeme de gestion de bases de données, alors l'Itanium ne sert juste à rien. Le cas du POWER est différent (et d'ailleurs c'est pour ça qu'on en est à la 8è génération…).
[^] # Re: Non !
Posté par BAud (site web personnel) . Évalué à 2.
L'itanium, à part au CEA et un peu à la R&D de EDF, il n'en reste plus, c'est cela ? (je vois que tu en parles au passé).
[^] # Re: Non !
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
J'imagine que depuis que Intel fait de l'AVX en 64 bits, cela n'a plus trop d'intérêt.
"La première sécurité est la liberté"
# systèmes d'exploitation
Posté par Antoine . Évalué à 8.
Seule Ubuntu ? Heu… Il y a les systèmes d'exploitation IBM, comme PowerLinux et AIX.
[^] # Re: systèmes d'exploitation
Posté par BAud (site web personnel) . Évalué à 5.
… ainsi que Red Hat, contrairement à ce qu'affirme Sam_from_MS<
cf. http://www-03.ibm.com/systems/fr/power/software/linux/
Le tout pouvant s'inscrire dans la gestion proposée par un système Z (bon, là je ne vous donne pas le prix, c'est indécent).
# Concentration?
Posté par Jean Gabes (site web personnel) . Évalué à 8.
Est-ce que sincèrement quelqu'un croit encore à l'avenir de "gros" serveurs quand les applications (vous savez, le truc réellement important au final) s'orientent massivement vers une scalabilité horizontale sans limite? Nos chers gros de l'internet font tous avec de petits serveurs jetables plutôt que des gros. Or leurs techniques sont de plus en plus reprisent par les sociétés "normales" (genre cac40 and co).
On est à l'air de l’élastique, avec des instance qui viennent et repartent. On a tous les outils pour. Seules certaines grosses applications d'entreprise (comprendre: usine à gaz) ne savent pas gérer cette logique (il faut voir ce qu'il faut faire pour juste rajouter un simple nœud applicatif à un ERP Oracle…).
Est-ce que ce processeur est techniquement génial? oui. Est-ce qu'il sera acheté par quelques gros groupes historiques? Oui sûrement. Est-ce qu'il va s'implanter largement et changer l'orientation du marché? Certainement pas.
[^] # Re: Concentration?
Posté par lasher . Évalué à 9. Dernière modification le 08 octobre 2014 à 09:18.
Si tu lis les slides que j'ai mis en lien, tu peux voir que le POWER8 permet la virtualisation, etc. Et comme ils ont une quantité impressionnante de cache sur le chip et la carte-mère, il y a un potentiel pour permettre à des applications qui nécessitent de traiter de gros volumes de données efficacement de traiter ces dernières encore plus vite. Ça ne veut pas dire que tu ne peux pas créer un machin cloud-esque (au contraire, si tu as un petit cluster/data center basé sur ce genre de processeurs, tu peux mettre dans un tout petit espace tout plein de cœurs/threads qui accèdent en parallèle à tout plein d'I/O. Ce genre de machine peut parfaitement servir de colonne vertébrale à un truc plus hétérogène avec des machines moins chères et qui se remplacent plus facilement.
Enfin, tu oublies qu'il existe tout un tas de services qui nécessitent une haute performance que les solutions de virtualisation à base de réseau distribué ne comblent pas, et dont la disponibilité se mesure en nombre de minutes de pannes par an. Lorsqu'on en est à vouloir ce genre de choses, on ne lésine pas sur le hard : de toute manière les ingés et le soft qui va avec coûtera bien plus cher.
Note bien : il est clair que ce genre de processeur est principalement fait pour des machines très haut de gamme. Ce que les gens ont tendance à oublier, c'est qu'au département de la défense US, IBM a de gros contrats, et qu'elle les mérite (certaines machines/certains processeurs sont conçus uniquement pour le DOD par IBM par ex).
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Le problème est que tes 100 threads partagent une bande passante mémoire pas si énorme. Surtout si tu compares la bande passante dispo par thread, pour 16 threads d'un cpu intel.
Il s'agit des applications critiques qui n'ont pas été prévu pour fonctionner en cluster. Le moteur de recherche Google est critique, mais il est en cluster sur des machines pas fiables du tout.
Depuis que les SSD existent, l'avantage des solutions "pro" de stockage tombent fortement.
Tu parles du HPC là, non ? Basé sur plein de powerPC (100k) et non du POWER il me semble.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par lasher . Évalué à 10.
Disclaimer : j'aime beaucoup les processeurs Intel. :-)
Voilà ce que je sais des processeurs Intel récents :
Xeon (Ivy Bridge récent) :
* L1 data = L1 instruction = 32 Kio chaque, privés, soit 16 Kio / thread
* L2 unifié = 256 Kio, privé, soit 128 Kio / thread
* L3 unifié = ~40 Mio max (partagé par 8 cœurs/16 threads), soit ~2,5 Mio / thread.
Tous les bus L1<->L2<->L3<-> sont de 8 octets, les lignes de 64 octets. Donc la latence est de 8 cycles entre 2 modules de cache. Comme il n'y a qu'un seul port d'écriture actif à la fois, si le L1 veut écrire dans le L2, et que le L3 veut faire de même, il y aura arbitrage et on doublera la latence de L1 ou L3.
L'horloge est cadencées à 3,2 GHz (avec l'option du turbo qui réduit la fréquence de tous les cœurs sauf un, qui monte jusqu'à 4 GHz).
POWER8:
* L1 data = L1 instruction = 64 Kio chaque, privés, soit 8 Kio / thread
* L2 unifié = 512 Kio, privé, soit 64 Kio de cache L2 / thread
* L3 unifié = 96 Mio, NUCA, partagé par tout le monde, soit 1 Mio / thread
* Apparemment: possibilité d'ajouter un niveau de cache L4 off-chip (mais j'ai pas vu de vraie descriptions pour ce cas)
Le processeur devrait tourner jusqu'à 4 GHz (soit 25% plus rapide que pour un chip à 3.2 GHz), mais je ne sais pas encore comment il va gérer l'énergie et la modulation automatique de tension/fréquence.
Le bus L2<->L1 est de 64 octets, ce qui permet de transférer une ligne de cache directement en un cycle. La bande-passante est donc au moins 8 fois plus importante que son équivalent sur puce Intel (là encore, pour L1/L2).
IBM annonce 4 Tio/s en bande-passante pour le L2 en crête (sans doute lorsque le banc de L3 que tu accèdes est local au cœur), et 3 Tio/s pour le L3. J'ai jamais vu ce genre de chiffres annoncés sur les chips Intel, même en crête. Ça me permet de commencer à répondre à tes remarques. :-)
Si ton appli est correctement optimisée, alors il y a des chances que traiter les ~100 Mio de données dispo sur le cache occupe le processeur « un bon moment ». Du coup, ~3 Tio pour 100 threads, ça me semble parfaitement raisonnable : ~30 Gio/s en moyenne par thread. En pratique, il y aura très certainement de nombreux échanges entre le L1 et le L2 (car 8 threads en concurrence, ça va forcément créer des conflits), mais ça tombe bien, le bus L1<->L2 est de 64 octets, donc transférer une ligne devrait donner une latence tout à fait correcte.
Hum, on parle de peta-octets de données produits chaque jour dans le cas de big data. Même avec des SSD, tu veux des I/O qui poutrent. Le problème n'est d'ailleurs pas tant de générer les données (à la limite, un « array » de SSD pourrait faire l'affaire), mais aussi de faire de l'analyse au plus tôt dessus (après tout, c'est à ça que « Big Data » se réfère : le besoin de générer plein de données, mais aussi de les traiter dans des laps de temps de plus en plus courts).
Oui beaucoup sont à base de PowerPC. L'une d'entre elles par exemple, est très sommairement (et vaguement incorrectement) décrite là : http://en.wikipedia.org/wiki/Cyclops64
Le chip Cyclops-64 est sorti en 2007, et était produit en 90nm, avec 160 threads et 80 unités flottantes. Aucun cache, que des scratchpads, avec un total de ~4.2MiB on chip (pour 2007, c'était pas mal du tout) qui était divisée entre SRAM partagée et scratchpad privé (configurable au boot). Un truc important : il y avait un énôÔôÔôÔôÔôÔôrme cross-bar pour la SRAM qui garantissait un modèle mémoire « séquentiellement constant » (sequential consistency de Lamport), un jeu d'instructions atomiques qui utilisaient des PiM (processing in memory), etc. Bref, un petit bijou technologique (et impossible à programmer pour des trucs génériques, il faut bien avouer : ça ressemblait plus à un truc embarqué pour du HPC qu'à une machine généraliste).
Mais même pour des clusters ou centres de calculs donnés, il arrive quand même que l'état US dépense pas mal pour des POWER car ils sont gonflés de partout : le bus L2 → L1 qui fait 64B (et pas 64b a priori) c'est 8 fois plus que ce que propose Intel sur ses archis type Xeon. En gros, on a limite 1 cycle = 1 ligne de cache, ce qui est quand même super pour tout ce qui est accès aléatoire. 96Mio de cache L3, c'est quatre fois plus que la plupart des processeurs Intel haut de gamme (et je te parle pas des 6×512Kio pour le L2). Leurs chiffres pour la bande passante supposent 4GHz soutenus, ce qui est complètement faisable depuis au moins le POWER6, et 3 à 4Tio pour la BP sur la puce, c'est quand même largement au-dessus de ce que propose Intel sur ses processeurs. Si en plus tu rajoutes jusqu'à 8 bancs mémoire (sur les cartes-mère Xeon que j'ai pu manipuler, c'était 4 bancs maximum), ça commence à faire vraiment pas mal. Et puis dernière chose, ils ont continué à foutre de la logique supplémentaire directement au niveau du contrôleur mémoire plutôt que d'en rajouter sur le chip, et ça, c'est très bien. Si tu rajoutes la connexion directe aux périphs PCI, ça permet réellement d'économiser en latence.
Encore une fois, c'est SUPER cher ces trucs, et IBM va plutôt tenter de vendre des licences AIX avec plutôt que de mettre Linux dessus. Mais ça reste un monstre en termes de bande-passante et « throughput ».
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela m'étonnerait beaucoup. J'imagine plutôt 2 ou 4 port d'écriture sur le L1 par exemple.
Cela dépend beaucoup de ton application. Typiquement pour une application serveur base de donné, c'est faux.
Cela ressemble à une architecture type CELL avec des powerPC à la place des coeurs SPU. D'ailleurs, cela semble tellement inutilisable que l'architecture de la PS4 est à l'inverse complètement lisse pour ne pas avoir à gérer des petits zones mémoires.
Tu parles de transfert L1->L2, c'est pas franchement aléatoire.
Oui, les caches énormes étaient à la mode, surtout avec l'Itanium. Mais cela coute hyper chère en silicium, et quand on voit l'architecture de la PS4, j'ai bien l'impression qu'il vaut mieux sacrifier 10Mo de RAM hyperrapide, contre le double de la bande passante RAM. Tu perds en performance sur le meilleur cas, mais tu gagnes sur le cas moyen, j'ai l'impression.
Je ne vois pas ce que tu veux dire. L'intégration du pipeline d'accès à la DRAM dans le cpu, est ce qui a divisé par 2 la latence d'accès des Athlons, ce qui rendait les Pentium4 ridicules à l'époque.
C'est pareil avec les chip x86 qui embarquent directement des liens PCI express, non ?
A l'époque, un POWER détenait le record de vitesse de compilation du noyau linux : ~15s de mémoire. La vitesse provenait pas mal des IO (lien à 1Go/s), qui était bien plus rapide sur mainframe que sur PC.
Mais aujourd'hui, avec les SSD sur port PCI, j'ai un doute.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Antoine . Évalué à 3.
Sur un benchmark "entreprise", le POWER 8 semble confortablement en tête :
Power8 @4.19ghz 80 core SAP benchmark
(pour ceux qui ont la flemme de lire : environ 60% plus rapide qu'un Xeon)
[^] # Re: Concentration?
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 08 octobre 2014 à 14:07.
J'ai la flemme certes, mais aussi dur de trouver des prix : peux-tu dire aussi 60% plus rapide qu'un Xeon pour combien de pourcents plus (ou moins) cher qu'un Xeon?
La performance pour la performance, ça doit concerner quelques projets dans le monde (ceux ne pouvant pas utilsier 2 machines plutôt qu'une pour le même taf). ce qui interesse le plus c'est le rapport performance/prix.
Sans le prix, avoir x% de perfs en plus interresse 0.00001% des acheteurs potentiels.
Quel est le but? Concurrencer Intel ou avoir une démo technologique?
Bref : "60%", on s'en fout, il manque la donnée la plus importante. Donc il vaut quoi ce truc, dans la vraie vie hors projets hyper-sépcifiques ne pouvant pas avoir 2 machines?
Note : 60% de plus, désolé mais ça casse pas non plus la baraque si on a besoin de vraiment plus qu'un Xeon.
[^] # Re: Concentration?
Posté par Psychofox (Mastodon) . Évalué à 5.
Faut arrêter de vivre au moyen âge Zenitram, ce genre de machines ne sont pas forcément si chères que ça (il y'a des petits modèles) et sont souvent utilisées de façon mutualisées via du partitionnement logique (LPAR) ou de la virtualisation. Les X% plus rapides peuvent être bien plus importants quand ça touche Y instances de serveurs.
Et ne pas oublier la question de la fiabilité. Parce que bon dans toutes les boites où j'ai pu bosser au fur et à mesure que les architectures sparc, power ou même les mainframes étaient mises de côté au profit du tout intel x86, la fiabilité se cassait la gueule. Faut pas se leurrer, les serveurs x86 ont beau avoir de la mémoire ECC et des cartes RAID hardware, ça reste des gros PC.
[^] # Re: Concentration?
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 08 octobre 2014 à 15:02.
Euh… Justement, c'estce que je fais : au moyen age, peut de paralélisation, de nos jours on sais pas mal diviser les tâches.
Donc tu sais, et tu peux répondre à ma question.
Pourquoi alors ne pas le faire plutôt que de partir dans la théorie?
Fournit des chiffres, puisque tu les connais!
Ca me rappelle la gué-guerre ATM (le truc parfait, tout est contractualisé dans les flux) vs IP (la grosse merde sans contrat de service), qui a gagné?
En fait, pas la peine de partir dans un autre exemple, l'histoire moderne montre que quasi tout le monde préfère la moindre fiabilité pour pas cher à la fiabilité extrème hors de prix.
Faut arrêter de vivre au moyen âge.
[^] # Re: Concentration?
Posté par totof2000 . Évalué à 3.
Ton commentaire prouve que tu ne sais pas de quoi tu parles, et ne donne vraiment pas envie de discuter avec toi.
[^] # Re: Concentration?
Posté par dinomasque . Évalué à 7.
C'est bien ça le problème : beaucoup d'application héritées du passé (ou codées en deçà de l'état de l'art) ont du mal avec la "scalabilité" horizontale.
BeOS le faisait il y a 20 ans !
[^] # Re: Concentration?
Posté par Zenitram (site web personnel) . Évalué à 4.
Je n'en doute pas.
Mais combien?
Mais à partir de quand ça vaudra plus le coup d'adapter le code que d'achter du matos hors de prix?
C'est mignon tout ça, mais ça fait très marché de niche que de vendre un CPU à une population d'entreprise dont le code vieux d'il y a 10-20 ans ne peut pas facilement être modifié (coûte cher).
Note : je sais très bien que ça existe, oui, pas de soucis dessus. reste à voir combien de temps ça va durer d'avoir assez de clients près à payer cher une machine pour ne pas redevelopper un programme. tu noteras qu'on m'accuse de moyen âge quand je parle de paralélisation, alors que tu dis que c'est pour gérer le moyen-âge qu'on ne peut pas paraléliser, c'est amusant de lire tout et son contraire en quelques commentaires.
[^] # Re: Concentration?
Posté par BAud (site web personnel) . Évalué à 5. Dernière modification le 08 octobre 2014 à 22:23.
Tu m'étonnes, tout de même, peut-être n'as-tu pas les bons mots-clés :/
https://www.google.fr/search?q=pricing+ibm+power me donne http://www-03.ibm.com/systems/power/hardware/s824/browse_aix.html
Soit, selon l'interlocuteur à qui tu t'adresses :
De toute façon, ensuite tu regardes les options :
Ce qui est le plus rageant, c'est que c'est souvent du code éditeur… notamment dans les applications de gestion. Un documentum pour des >100k documents ou l'utilisation d'ETL comme datastage dont le coût d'entrée est à 100 k€ plutôt qu'un talend un peu plus raisonnable avec ses 20 k€… (sans les dévs, bien sûr :/).
Bref, c'est un monde que tu n'as sans doute pas eu le temps de voir lors de ton passage chez l'opérateur historique (mais qui existe encore).
Pour autant, lorsque tu es sur des applications avec uniquement de la scalabilité verticale, ce genre de serveur est très utile (et pour les problématique de PRA aka plan de reprise d'activité, tu l'achètes au minimum par paire voire par triplet…).
Donc, oui, réécrire les applications serait possible (l'exemple du projet NACA est une voie). Mais mener un projet sur trois ans n'est pas abordable pour beaucoup d'entreprises…
[^] # Re: Concentration?
Posté par lasher . Évalué à 3.
C'est pour ça que j'ai parlé de Ferrari ailleurs : le prix est très élevé en général, et comme tu dois acheter tout le matos kivabien autour généralement pour faire un nœud, il faut avoir un réel besoin pour la version haut de gamme. Par contre comme d'autres l'ont dit, il existe des versions 6 cœurs, à genre 3 GHz, et qui n'atteignent pas les bornes des limites (mais ça restera quand même vachement plus cher qu'un Xeon en moyenne).
[^] # Re: Concentration?
Posté par X345 . Évalué à 1.
Dans le monde d'aujourd'hui un serveur avec 384Go de RAM, ça vaut moins de 10k€. Donc on peut largement faire une compilation du noyau Linux en mettant les sources directement en RAM.
[^] # Re: Concentration?
Posté par xcomcmdr . Évalué à 2.
J'avais déjà tout en RAM (source + compilation + package pour installer) avec 4 Go de RAM en 2008 sur mon Core2Duo. Et ça prenait 3 heures pour tout compiler, 30 minutes pour compiler que ce dont j'avais besoin (surtout au niveau des pilotes/modules).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Concentration?
Posté par barmic . Évalué à 4.
C'est aussi ce qu'on trouve dans les cartes graphiques que nVIDIA arrive à bien vendre (avec des galère en plus niveau utilisabilité parce que la gestion de la mémoire est encore plus tordu) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Les GPU sont complexes à programmer, mais la puissance de calcul disponible est 100x supérieur. Heureusement, cela devient de plus en plus facile à utiliser.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par X345 . Évalué à 7.
Non, non, non et non. Comparer les 2496 """cœurs""" d'un GPU à 20 cœurs de Xeon, ce n'est absolument pas pertinent parce qu'un cœur de GPU n'a rien à voir (mais alors rien à voir) avec un cœur de CPU.
Sur une workload très favorable, la carte nvidia la plus puissante est à peine 6x plus rapide qu'un dual Xeon.
https://developer.nvidia.com/cublas
Le speedup est du même ordre sur les Xeon Phi (3x-8x).
http://www.intel.com/content/www/us/en/benchmarks/server/xeon-phi/xeon-phi-fsi.html
Entre du code CPU optimisé et du code GPU (ou Xeon Phi), faut s'attendre à un speedup de 3-8x, pas plus.
[^] # Re: Concentration?
Posté par barmic . Évalué à 3.
Il y a aussi (surtout ?) la problématique de l'accès mémoire. Il faut travailler au maximum avec des données qui sont déjà dans la RAM de la carte si tu commence à faire des aller-retour entre la RAM principale et celle de la CG, OpenCL/CUDA ne sont peut être plus pertinent.
Du coup :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je parlais de puissance disponible (max) pas de performance réelle.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par X345 . Évalué à 5.
On est toujours très très très très très loin du 100x.
Performance théorique :
Nvidia K40 4.29 Tflops (en single précision)
http://www.nvidia.com/object/tesla-servers.html
A la main, je trouve :
2880 Cores * 2 Op/Cycle * 0.754 Ghz = 4343.0 GFlops (donc proche du chiffre de nvidia)
2 opérations par cycle, je m'appuie sur le fused-multiply-add
Intel Xeon E5-2697v3
14 Cores * 16 Op/Cycle * 2.6 Ghz = 582.0 GFlops
16 opérations par cycle, je m'appuie sur le fused-multiple-add sur des registres AVX de 8 flottants.
http://ark.intel.com/products/81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz
https://stackoverflow.com/questions/19134375/how-to-derive-the-peak-performance-in-gflop-s-of-intel-xeon-e5-2690
Donc au mieux le plus puissant des GPU nvidia, en puissance théorique, est 7.46x plus puissant qu'un seul Xeon.
Bref, on est très loin d'avoir un rapport 100 entre la puissance d'un CPU et d'un GPU, même de manière théorique.
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Il y a tout de même plus de contraintes d'utiliser du SIMD large par rapport à des GPU (un comble). Mais bon le SIMD 512 bits, efficace c'est récent, avant tu avais une seul multiplication même en SSE.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par X345 . Évalué à 7.
Excuse-moi pour l'agressivité, mais purée t'as pas peur de la contradiction !
J'affirme, en fournissant des références (benchs de Nvidia à l'appui), qu'en pratique les GPU sont 3-8x plus rapides que les CPUs (et non pas 100x).
Tu rétorques qu'en théorie (peak flops), les GPUs sont plus puissants. Je réponds, là encore références à l'appui, que le rapport peak flops théorique GPU/CPU atteint 10x au max (7.5x dans mon exemple).
Et tu reviens en disant que y'a plus de contraintes pour programmer du SIMD large que des GPU, donc qu'en pratique les GPUs sont plus avantageux.
Au final, t'as pas fourni une seule référence pour justifier le fait que les GPUs seraient 100x plus puissants que les CPUs. J'entends ça souvent, et c'est juste complètement faux. Le rapport c'est 10 (au mieux), pas 100, faut arrêter de se laisser avoir par le marketing de nvidia comme une grand-mère devant les pubs de TF1.
En plus, tu affirmes des choses qui sont factuellement fausses.
L'intructions MULPS (multiplication de 4 flottants en une seule instruction) est incluse dans le jeu d'instruction SSE qui date du… Pentium III.
Il n'y a pas de SIMD 512 bits dans les CPUs (à moins de considérer le Xeon Phi comme un CPU).
16 opérations par cycle, c'est multiply-add (2 opérations) sur 8 flottants (256bits, 8x32bits), instruction VFMADD123PS des processeurs Intel Haswell.
Encore une affirmation en l'air, et franchement discutable. Déjà, en pratique, on arrive très bien à utiliser le SIMD 256bits (benchs qui montrent un rapport 3-8x entre les CPUs et les GPUs).
Ensuite, sur un CPU y'a une gestion de la cohérence des caches et des prefetcher hardware ce qui facilite grandement la programmation par rapport à un GPU où il faut gérer ces choses là à la main.
D'autre part, les GPUs schedulent leurs threads par wraps de 32 threads, qui doivent executer la même instruction pendant un cycle (ce qui revient un peu à du SIMD, Single Intruction Multiple Data). Je me repète mais à un instant donné, on a des groupes de 32 cœurs qui exécutent la même intruction sur un GPU.
Bref, pas vraiment plus de contraintes que du SIMD…
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à -3.
Non, c'était mes souvenirs. Le MULSP c'est du simple précision, et c'est 4 multiplications seulement, qui prennent 2 cycles, et non un seul.
Actuellement, tu prends 16 ops en un seul cycle. L'avx date de quand ? 2 ans max.
La grosse différence, c'est que tu n'es pas obligé d'avoir les adresses mémoires contigües contrairement au SIMD. Un vecteur load/store pourrait exister, mais ce n'est pas encore fait, sauf erreur. La différence est que cela revient à pouvoir exécuter la même fonction sur 32 éléments totalement différent, contrairement au SIMD classique.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par X345 . Évalué à 7.
mulps (packed single), le throughput est de 1 cycle depuis Nehalem au moins. Donc c'était 4 instructions par cycle. Après peut-être que sur le Pentium III, ça prenait 2 cycles. Mais on va peut-être pas comparer des GPUs de 2014 avec des CPUs de 1999…
https://software.intel.com/sites/landingpage/IntrinsicsGuide/
J'ai comparé les dernières générations de chez Intel et Nvidia. L'architecture Kepler date de moins de deux ans aussi. Forcément, si tu compares un GPU de la semaine dernière avec un CPU d'il y a 3 ans, peut-être que le rapport peak flops va atteindre 15. Si tu compares un CPU desktop avec un GPU desktop, le rapport peut aussi atteindre 15. Mais on est toujours pas sur du 100.
Sur un GPU, la latence vers la mémoire de la carte coute une fortune. Donc clairement, en pratique, c'est pas tellement faisable d'aller cherche des trucs n'importe où. Sur un CPU aussi tu peux t'amuser à set un à un les composantes d'un registre SIMD. C'est lent mais ça marche, comme ramener les données de la mémoire de la carte vers la mémoire "locale" incluse dans le chip du GPU. Enfin, vraiment c'est pas un bon argument.
D'autant plus qu'en AVX2, y'a des intructions qui aident pour ça, par exemple VGATHER.
Après ma position ce n'est pas que les GPU sont inutiles, loin de là. C'est juste que parler d'un rapport 100, c'est n'importe quoi. Ni en théorie, ni en pratique, on atteint le rapport 100. Même en comparant un CPU d'il y a trois ans à GPU de cette année.
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ok. J'étais rester sur des GPU avec >1 TFlops de puissance, et des cpu qui tournait à 60 Gflops. (2 instructions fpu/cycles/cpu).
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par lasher . Évalué à 6.
Hum, depuis au moins le Core 2, les CPU Intel sont capables d'effectuer une addition double précision SIMD et une multiplication double précision SIMD en parallèle et en un cycle. Donc 4 FLOP/cycle.
[^] # Re: Concentration?
Posté par lasher . Évalué à 3.
Hum, en 2007, Cyclops64 te promettait 80 GFLOPS soutenus en double précision, et une réelle généricité des applications. Les cartes Nvidia de l'époque ne pouvaient pas en dire autant.
[^] # Re: Concentration?
Posté par lasher . Évalué à 2.
Concernant le lien avec le Cell BE — oui ça ressemble beaucoup, mais avec quelques grosses différences :
fetch-and-addest en réalité plutôt unadd-and-return-old-value, ce qui permet de faire de l'overlapping, contrairement à la sémantique duload-modify-writeavec verrouillage de ligne de cache ou même du bus.Après, évidemment il y a plein de soucis, du genre le
mallocdu système alloue sur le tas, et donc en DRAM. Il faut ensuite utiliser des variantes spécialisées et effectuer des mouvements mémoire à la main entre DRAM et SRAM. C'est bien entendu contraignant.Quand on m'a expliqué l'archi et l'OS/Runtime qui tournait dessus, la première chose que je me suis dite c'est « ça doit être le rêve pour un expert en parallélisme, et un cauchemar pour un programmeur normal ».
Un de mes anciens collègues avait développé un cache logiciel sur cette machine et le Cell et démontré que l'overhead était minimal si tu choisissais un protocole de constance mémoire beaucoup plus faible que la cohérence de cache classique.
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Quel est l'intérêt de ça, si tu fonctionnes avec des threads pas franchement synchronisé ? Je comprends l’intérêt de l'ordre pour un cpu localement, mais pas pour l'ensemble des cpus. Un retard d'écriture venant d'un write buffer ou d'un retard de thread, quelle différence ?
Lequel ?
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par lasher . Évalué à 2.
Location Consistency, un truc qui est principalement de la recherche.
[^] # Re: Concentration?
Posté par X345 . Évalué à 3.
Ça c'est plus vrai depuis au moins 5 ans :
Bande passante : L1<->L2
Nehalem : 32Bytes/cycle
Sandy Bridge : 32Bytes/cycle
Haswell : 64Bytes/cycle
http://www.anandtech.com/show/6355/intels-haswell-architecture/9
[^] # Re: Concentration?
Posté par lasher . Évalué à 2.
On ne parle pas de la même chose. Je parle de latence, tu parles de bande-passante. :)
Lorsque j'avais fait des micro-benchmarks sur Nehalem EP et EX, j'avais les mesures suivantes :
Comme les caches sont configurés en « write allocate », une écriture en mémoire pour un mot = load + store, ce qui réduisait d'environ 25% la bande passante en pratique lorsqu'on faisait du write-only.
Sur Sandy Bridge au pifomètre je m'attends à quelque chose de sensiblement équivalent.
[^] # Re: Concentration?
Posté par X345 . Évalué à 1.
Oui, effectivement, on va essayer de parler de la même chose sinon aucun risque qu'on avance :)
On voulait connaître la largeur du bus entre le L1 et le L2 sur un Xeon. Si la "bande passante" est de 64Bytes/cycle, j'imagine que le bus fait 64Bytes, non ? A moins qu'on soit capable de transférer des données plusieurs fois pas cycle sur le bus L1<->L2. J'en ai sincèrement aucune idée.
Le lien anandtech de mon post précédent indique une latence ("fastest load to use") de 4 cycles pour le L1 et 11 pour le L2. À moins que ça ne corresponde pas à la latence.
Au final, j'ai du mal à me représenter comment ça marche.
[^] # Re: Concentration?
Posté par lasher . Évalué à 4.
Lorsque tu transfères une ligne d'un niveau à un autre, cette dernière ne peut être utilisée que si l'intégralité de la ligne a été transférée. Une ligne de cache sur x86 fait 64 bytes. Le bus a une largeur de 8 bytes. Donc pour transférer 64 bytes, il faut 8 transferts au total. Si Nicolas a raison et qu'il existe plusieurs ports d'écriture et plusieurs ports de lecture (en tout cas sur les Nehalem ça ne semblait pas vrai du tout quand j'avais fait mes benchs), alors la latence et la bande-passante peuvent avoir sérieusement augmenté1. Donc pour résumer : au moins pour les micro-archis Nehalem et SandyBridge, à ma connaissance il n'y a qu'un seul port de lecture et un seul d'écriture utilisables pour les L1 et L2 (qui sont privés). Le L3, ça dépend du modèle. Par exemple sur les Nehalem EP, c'est pareil que pour les L1/L2, mais pour les Nehalem EX, ils utilisent un cache de type NUCA, avec un bus segmenté qui peut allonger la latence jusqu'à 8 cycles, mais augmente la bande passante de façon significative par rapport aux EP.
Au passage, les 32 bytes/cycle annoncés sont expliqués dans le papier que je référence plus bas : sur les archis Intel, il y a 5 ou 6 ports : 1 port pour l'ALU, 1 port pour le × flottant, un pour le + flottant, un pour les loads, et un pour les stores (parfois certaines archis on 2 ALU, mais pour l'architecture Nehalem je crois pas). Si tu émets un store et un load « en même temps » en utilisant les SSE, alors tu as effectivement bougé 32 bytes depuis les registres vers le L1. Par contre, je renvoie à la figure 4 du papier mis en note : s'il faut aller chercher la ligne de cache jusqu'en L3, alors ça peut prendre jusqu'à 14 ou 20 cycles (latence).
Non. Si tu charges une ligne depuis la RAM jusqu'au L1, puis jusque dans un registre, alors tu vas payer la latence au prix fort. Par contre, si tu effectues des opérations arithmétiques avec les données accédées, tu vas bénéficier des effets de cache (temporalité : tu réutilises les mêmes adresses mémoire; et localité : tu n'as pas besoin d'aller chercher les mots « voisins » du mot que tu avais initialement chargé). Comme en plus il existe des prefetchers extrêmement efficaces sur archi x86 (si tu as un cache miss, alors la ligne de cache suivant celle que tu veux est automatiquement préchargée; sur Intel, il y a un pattern matcher d'adresses, et tant que ça reste dans une page physique, le prefetcher va reconnaître le pas de déplacement et précharger automatiquement les lignes qui correspondent), tu n'as généralement pas trop à t'inquiéter de payer la latence à chaque fois : tu vas juste payer le prix fort de temps en temps.
Je renvoie à cet article qui décortique pas mal la micro-architecture du Nehalem EP. J'ai bossé avec l'un des auteurs : ils sont très sérieux et rigoureux. ↩
[^] # Re: Concentration?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Cela m'étonnerait beaucoup. Même dans la DDR, il y a un mode de transfert qui demande la data qui intéresse en premier.
"La première sécurité est la liberté"
[^] # Re: Concentration?
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Oui enfin justement là, je pense que l'exemple de Google n'est pas forcément terrible puisqu'ils sont à l'origine de OpenPower et qu'ils sont en train d'élaborer une carte mère basée sur des power8 avec Tyan.
Voir : http://www.lemondeinformatique.fr/actualites/lire-impact-2014-google-montre-une-carte-mere-sur-base-ibm-power8-57333.html
[^] # Re: Concentration?
Posté par X345 . Évalué à 4.
Franchement… À moins d'avoir des besoins très très spécifiques, acheter ce genre de machine pour faire de la virtualisation cloud-esque comme tu dis, c'est complètement idiot. C'est hyper hyper-cher, le coût des machines arrive rapidement dans le M€, et pour 20% de l'investissement du tu auras une solution à base de serveurs classiques Intel aussi performante sur les workload classiques (web, analyse, base de données etc.).
Si les grands du web c'est à dire les boites manipulant les plus gros volumes de données aujourd'hui utilisent de bêtes serveurs x86, c'est parce que c'est rentable. Et puis, en termes de disponibilité, c'est pas mal Google, non ? En ce millénaire, la fiabilité est apportée par le logiciel, et non par le matériel, tout simplement parce que c'est bien plus facile de faire du logiciel fault-tolerant que du matériel fault-tolerant.
Enfin, apparemment, ça amuse tout le monde de s'extasier sur la grosse techno hyper performante qui brille dans le noir. Reste qu'en pratique (sauf résistance au changement, habitudes historiques), c'est pas vraiment utilisable.
Après je ne nie pas l'utilité sur des workload très spécifiques (je pense à des grosses simulations physiques ou t'as besoin de 256To de mémoire partagée), je ne nie pas l'utilité.
[^] # Re: Concentration?
Posté par Psychofox (Mastodon) . Évalué à 0.
Tu le sors d'où ton chiffre du million d'euro la ? D'un chapeau ? IBM sort des machines d'entrées de gamme avec des processeurs Power (qui restent très performantes d'ailleurs) et ça coûte certe plus cher que des machines DELL/Cisco/HP/whatever, mais pas de beaucoup. Comme partout, il ne faut pas se fier aux prix listes.
[^] # Re: Concentration?
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 08 octobre 2014 à 15:06.
Sacrément étonnant quand même que ceux qui doivent acheter sont tellement idiots (surtout pour des logiciels libres qu'on peut recompiler) pour ne pas prendre un peu plus cher pour un gain important.
A moins que…
bon, tu les donnes les chiffres? Perso, les prix des Xeons sont dispos, et pas "prix liste", les vrais. Si les Power sont top au niveau prix, on doit pouvoir avoir des gens qui nous les donnent ces prix.
Perso, quand j'ai pas de prix de vente, l'expérience m'a appris que c'est parce que ce n'est pas compétitif et qu'on achète du coup pas mal le marketing autour, donc bon…
[^] # Re: Concentration?
Posté par totof2000 . Évalué à 4.
Appelle un commercial IBM qui te les donneras. Ce genre de truc c'est un peu à la tête du client : plus tu as de matos acheté chez IBM, moins ça te coute cher à l'achat, parce que le bénéfice se fait sur la maintenance.
[^] # Re: Concentration?
Posté par Jerome . Évalué à 4.
Parce qu'un tarif en fonction du volume c'est un principe commercial exclusif à IBM ?
[^] # Re: Concentration?
Posté par X345 . Évalué à 5.
Pour vous répondre à tous (un peu en vrac), effectivement IBM vend des machines d'entrée de gamme avec des processeurs Power dedans. Quand je parlais de machines à plusieurs M€, je faisais référence aux mainframes.
Si on compare un peu les gammes, on a :
J'ai pris le truc le plus compétitif, m'a-t-il semblé :
IBM Power System S822
8284-22A4
Dual Power8 10C 3.8Ghz
128GB RAM
2x 146GB SAS 15K
21 000$
http://www-03.ibm.com/systems/power/hardware/s822/browse_aix.html
Pour le même prix, on peut avoir 2 serveurs Dell:
Dell PowerEdge R730
Dual E5-2697 14C 2.6Ghz
128GB RAM
2x 300GB SAS 15K (pas trouvé de 146GB)
Carte réseau 2x10Gb + 2x1Gb
10 900$
http://configure.us.dell.com/dellstore/config.aspx?oc=pe_r730_1356&model_id=poweredge-r730&c=us&l=en&s=bsd&cs=04
Donc grosso modo, on a :
Intel 56C 2.6Ghz 256GB RAM
Power8 20C 3.8Ghz 128GB RAM (Frequence +46%, Cœurs -64%)
Donc effectivement, ça a l'air relativement compétitif, mais pas exceptionnel.
[^] # Re: Concentration?
Posté par Zenitram (site web personnel) . Évalué à 1.
Faudrait voir avec un CPU "à jour" genre E7-8893 v2 qui tourne à 3.4 GHz (3.7 Ghz si on n'utilise pas tous les coeurs) donc kif kif au niveau fréquence, et on peut en mettre 8 ensemble (donc 48 cores dans une machine) : est-ce qu'un Power8 est beaucoup plus rapide pour une programme incapable de faire du multi-thread?
Il serait interessant de connaitre la performance de certains programmes mono-thread sur le top de chaque constructeur, pour ceux qui ne veulent pas parler de prix.
[^] # Re: Concentration?
Posté par X345 . Évalué à 6.
Oui, sauf que quand tu commences à mettre 8 processeurs par machine tu quittes le segment ou les processeurs Intel sont les plus rentables. Le rapport prix-puissance des E7-8893 est bien plus mauvais que celui des E5-2697.
E7-8893 v2 6C 3.4Ghz 6000$
E5-2697 v3 14C 2.6Ghz 2700$
Typiquement si tu montes une machine avec des E7-88xx, tu va très vite fait arriver dans les 100k€ (et bien plus). Tout devient plus cher, les cartes mères coutent une fortune, les boitiers aussi etc.
Mon idée c'était de comparer Power8 vs. Intel tous les deux à l'endroit ou ils ont le meilleur rapport prix/puissance.
[^] # Re: Concentration?
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 08 octobre 2014 à 18:00.
On parlait de 2 cas différents :
- moyen de gamme : est-ce que Power8 est interessant? tu y a répondu (que je traduis par : bof, ça tue pas des masses)
- cas historiques : parait que Power8 fait mieux qu'Intel pour des vieux programmes monno-thread, je serai tout autant curieux. J'ai pris 8 sockets pour le fun, on peut prendre du E5-1630 à $400 qui tourne 10% moins vite (n fréquence, à voir en perfs) que le plus rapide des Power8 (4.2 GHz) et behcer un programme mono-thread.
Bref, je cherche des cas d'usage où le Power8 est interessant, sorti de la force commerciale d'IBM pour le refourguer aux grosses entreprises, en package, sorti des discours marketing repris par les fans avec quelques cas hyper spécifiques.
Après, parait qu'OVH teste une offre, faudra voir si le but est de draguer les gros comptes qui veulent prendre du Power8 absolument sans vraiment réfléchir, ou si le rapport perfs/prix vaut le coup pour plus de monde.
[^] # Re: Concentration?
Posté par BAud (site web personnel) . Évalué à 4.
Bah, le bas de gamme de ce genre de système se fait enfoncer par les Intel, comme tu t'en doutes un peu (puissance/coût), pour une fiabilité similaire au final.
Avec le power v8, peut-être que le moyen de gamme s'est amélioré, mais vu de loin cela paraissait le pire des mondes :
Autant viser le haut de gamme,
Bref, tu me donnes ton adresse pour le consulting gratuit ? (faut bien facturer…) :D
[^] # Re: Concentration?
Posté par Dabowl_75 . Évalué à -2.
recherche ovh et power8 dans google
# euh...
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
C'est surtout que les processeurs intel proposaient presque la même puissance pour 10 fois moins chère. Quand il a été plus facile de mettre 2 cpu cote à cote, les autres cpu ont perdu leur intérêt. Ensuite, vu les volumes nécessaires pour la microélectronique, seul des applications grand publique peuvent fonctionner.
"La première sécurité est la liberté"
# Power8 chez OVH
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
OVH vient d'annoncer que sa plateforme Cloud Runabove va proposer du power8. On peut disposer jusqu'à 176 threads :-) https://www.runabove.com/index.xml#compute
Je pense que ça va aider à la "démocratisation" du power8. Vu les prix, ça reste réservé aux entreprises bien sûr, mais ce n'est excessif je trouve (700€/mois sans compter le traffic)..
[^] # Re: Power8 chez OVH
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela va être facile de faire quelques benchs avec ça.
"La première sécurité est la liberté"
[^] # Re: Power8 chez OVH
Posté par Kerro . Évalué à 5.
Si ça tente quelqu'un, je paye la location d'une de ces machines pour faire des tests.
Soit la version S à 32 $ par mois, soit la version monstre à l'heure.
Et en plus il serait bien que ce soit avant la fin du mois, car fin de mon exercice comptable (j'ai de l'excédent et j'ai arrêté d'aller aux putes). Ce point n'est pas essentiel.
Pour me joindre : w5kg4ov9zzmko2v@jetable.org
[^] # Re: Power8 chez OVH
Posté par claudex . Évalué à 4.
Je n'ai aucune idée de comment benchmarker ça correctement donc je ne me propose pas. Par contre, s'il faut de l'aide (je ne vois pas bien comment mais on ne sait jamais), je veux bien participer. En tout cas, je suis assez curieux du résultat et ce serait sympa de le publier quand ce sera fait.
« 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: Power8 chez OVH
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 10 octobre 2014 à 22:41.
Il y a deux manières de voir :
Pour motiver certains, j'ai quelques notes prises de-ci, de-là sur http://cookerspot.tuxfamily.org/wikka.php?wakka=Blog20070501Benchmarking mais si vous avez d'autres idées, elles sont les bienvenues ;-)
oui, bon, ok, full disclosure, je ne sais pas le faire par moi-même, je suis architecte et je ne le ferai pas par moi-même mais je veux bien mettre la main à la pâte avec ceux qui auraient envie de se lancer. Il nous reste 2 mois pour le faire quoi au vu de la propal' de Kerro< Des tests de perfs, ça se fait sur 3 semaines voire 5 semaines en comptant les délais à la Numérobis :-) vu qu'il faut bien produire les rapports.
Bon, cela ne sera représentatif que :
Sinon, bah yaura que des chiffres :/ (et des courbes, ça fait toujours joli les courbes, l'interprétation serait plus intéressante mais bon…).
Merci Kerro< de la proposition en tout cas, j'espère que cela se mette en place ; pour se coordonner il y a moyen de monter wiki + ML en une journée via tf.o au besoin, sous condition que les contenus soient publiés sous licence libre (au choix) :-)
[^] # Re: Power8 chez OVH
Posté par X345 . Évalué à 3.
Pour info, j'ai lancé les deux instances (S, 8 threads et 2XL, 176 threads) pendant 1h, et la distribution proposée est Fedora 19.
/proc/cpuinfodonne des cœurs cadencés à ~3Ghz.Sur la 2XL :
[^] # Re: Power8 chez OVH
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Je peux juste dire que les micro benchs ont rarement un intérêt, car ils sont encore plus difficile à interpréter que les benchs applicatifs.
J'imagine qu'un "make -j" d'un noyau Linux particuliers, donnera une bonne idée de la vitesse des CPU, et du système d'IO sur des données petites.
Des tests utilisant des compresseurs video (ffmpeg, mencoder) ou audio (lame) peuvent servir pour les calculs lourd (entiers ou flottant selon les options).
7zip/gzip peuvent servir pour le bench de calcul d'entier.
Je crois qu'il existe des clients pour exciter des serveurs web et mesurer les temps de réponse, il doit donc être possible d'installer des applications web commune, et comparer ses temps, avec un PC classique.
Utiliser des vrais applications permet aussi de mesurer le degré d'adaptation/d’adaptabilité des softs avec le nouveau cpu. Si le cpu a plein de particularités pour aller vite, mais qu'aucun soft ne les gère, un micro bench dira que le cpu est le plus rapide, mais il n'aura aucun intérêt pratique. A l'époque de l'arrivé 64 bit, les soft de compression vidéo n'utilisant pas de code assembleur était forcément plus lent que leur version 32 bit optimisé à la main.
"La première sécurité est la liberté"
[^] # Re: Power8 chez OVH
Posté par claudex . Évalué à 4.
J'imaginais installer un drupal et jouer avec ab en localhost. C'est vrai qu'une compilation (linux, libreoffice, firefox) est intéressante. Mais ces deux applications dépendent beaucoup des IO, du coup, ça risque de biaisé fortement le résultat.
« 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: Power8 chez OVH
Posté par lasher . Évalué à 3.
Mouais. Les SPEC utilisent gzip/bzip2 (en fonction des années), gcc (une vieille version), des noyaux de type traversée de graphe, algèbre linéaire creux, etc., et du coup les fabricants de processeurs et compilateurs font du fine-tuning dessus pour avoir un joli score… :)
Je suis complètement pour l'utilisation d'applis plus grosses pour faire des tests en « conditions réelles » hein, mais par exemple compiler un gros projet ça risque de stresser plus ton hdd/ssd que ton processeur au final, et donc tes résultats seront bien pour ta machine perso, mais pas trop pour généraliser.
Les micro-benches sont intéressants pour voir si les limites théoriques annoncées par les constructeurs sont atteignables facilement. Genre on nous annonce « x GB/s » sur le cache L2 ? Ah oui, mais seulement en lecture, car en écriture on doit faire avec la politique d'allocation « write allocate » (c'est-à-dire on charge la ligne, puis on écrit). Du coup ensuite on passe (pour du x86 par ex) par des « non-temporal stores » et on s'aperçoit qu'en fonction du processeur, ça fait réellement ce qu'on veut ou pas. Je trouve que c'est quand même important d'en être conscient quand on écrit du soft pour la performance.
[^] # Re: Power8 chez OVH
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ce n'est pas une compilation Java non plus (spécial dédicace à Eclipse), si le PC a assez de RAM, j'imagine que la totalité des sources finira dans en cache très rapidement.
Oui, si tu peux te permettre d'écrire du code spécifique pour une machine, et que tu ne réutilises pas de code, ou que tu ne veux pas écrire du code "portable".
"La première sécurité est la liberté"
[^] # Re: Power8 chez OVH
Posté par lasher . Évalué à 2.
Mon code était portable, mais il était clairement écrit pour qu'icc comprenne quelles optimisations il pouvait faire. ;)
Après, la portabilité des performances, c'était un autre problème…
# Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par totof2000 . Évalué à 3.
Faux, Sun (enfin maintenant Oracle) est toujours dans la course : http://www.enterprisetech.com/2014/08/13/oracle-cranks-cores-32-sparc-m7-chip/
Comme dit plus haut, il faut bien comprendre que ce type de processeur vise un segment de marché particulier, avec besoin de perfs précises. Les processeurs x86 sont loin d'égaler ces bêtes de courses. Ils sont moins cher suffisant pour certains types d'application, ce qui explique leur utilisation, mais pour d'autres types de traitements et de calculs, ils ne suffisent toujours pas.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 1. Dernière modification le 08 octobre 2014 à 11:56.
Loin? 40% de moins, c'est pas loin, c'est juste derrière.
Ensuite, il faut voir le domaine : FPU, CPU ou IO. Et clairement le PC sacrifiait les IO par rapport au CPU.
Le bench plus haut mesurait des machines 8 sockets. Je serais curieux de voir les performances du même genre d'applications sur 8 machines mono-socket.
Et puis depuis que AMD ne fait plus grand chose, intel se concentre sur le low power et semble avoir abandonné la course à la puissance brute (les core iX offrent peu d'augmentation de performances brutes à chaque génération). C'est dommage. Il est logique donc d'avoir des puces qui sortent avec cet objectif unique en tête.
Si Intel sort une puce avec des instructions d’accélération de compression (pour le mod gzip d'http) et des instructions pour les hash les plus utilisé, en plus des instructions AES, si il augmente drastiquement la bande passante avec la RAM (x2 ?). Il peuvent retrouver une bonne place dans les benchmarks "base de donné".
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par hervé Couvelard . Évalué à 5.
lol ? c'est comme si tu expliques qu'une ferrari et un golf5 turbo c'est vraiment peu de différence en vitesse de pointe car 180 au lieu de 300 c'est juste derrière. Oui c'est pas devant c'est clair, mais sur 8 heures de routes vous allez pas du tout au même endroit.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 08 octobre 2014 à 14:13.
lol, c'est comme les gens qui admiraient le concorde (l'avion) : super démo technologique, ça va trop trop vite, mais un plantage gigantesque au niveau commercial. C'était beau, et?
Pour revenir à ta voiture, 300 km/h quand c'est limité à 130 a peu d'utilité. Et ici, en informatique, on peut faire aussi autrement (mettre deux machines, genre avoir 180 km/h + 180 km/h donne 300 km/h, si il faut comparer).
Est-ce que la différence (1 Power contre 2 Xeon) vaut le coût (autant en achat qu'en énérgie)? Quand est-ce vraiment impossible de mettre 2 Xeon et qu'on peut mettre ce Power? Plein de questions sans réponse, on a juste une démo la.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par totof2000 . Évalué à 2.
Oui ça vaut le coût, pour plein de raisons. Et si tu veux savoir, renseigne-toi auprès de banques par exemple.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par hervé Couvelard . Évalué à 7.
je sais que tu as un peu de mal à comprendre dès que cela sort de combien ça coûte, combien ça rapporte.
Je ne suis pas un spécialiste des processeurs, mais à moins que j'ai loupé un épisode quelque part, je n'ai pas l'impression que tu sois plus avisé que le service R&D de IBM.
Alors probablement que pour lire une vidéo, il vaut mieux un P4 gratuit de récup (qui explose d'ailleurs TOUS les rapport performance/coût) mais peut être que pour certains projets, il vaut mieux mettre un outils en place ou tu n'as pas à gérer le parallélisme/conflit/whatever d'une ferme de machines tournant en même temps.
Par delà même la notion de bénéfice immédiat du produit, on peut aussi regarder quels sont les avantages du travail et de la recherche sur ce processeur et ce qu'il donnera peut être dans l'informatique de demain.
Parce que de la même manière les formules 1 ne servent strictement à rien : elles ne servent qu'a tourner en rond en cramant de l'essence et des pneux sur un circuit fermé : Cela ne sert à rien, il suffit de mettre 10 super 5 sauvées de la casse à la place de chaque formule 1 pour arriver au même rapport kilomètres/temps.
Enfin, je réagissais à 40% de moins c'est rien, c'est juste derrière : ce n'est pas juste derrière c'est pratiquement un rapport du simple au double.
Tu ne peux pas arriver à sortir de cette vision étriqué de combien ca rapporte. Tout le monde se plains qu'il n'y a pas assez d'argent dans la recherche et dès qu'un truc est fait tout le monde explique qu'on peut faire la même chose avec 3 pc de salon qu'on fait tourner en même temps. Tout le monde explique que ton projet c'est une perte de temps et que tu ferais mieux de contribuer à un qui existe déjà. tout le monde t'explique que le monde il est comme ça et que tu vas pas le changer. Les gens sont un peu coincés dans une vision étriqué de leur petit monde.
Plus je lis les posts, plus je suis effaré du manque d'empathie les uns envers les autres. Ce terreau ne fait que permettre aux mauvaises graines comme semblent le dénoncer systemd et gol de pousser. Vous ne pouvez pas à chaque fois démonter les gens sans trop réfléchir à ce qu'ils proposent et vous plaindre de l'ambiance de merde qui se développe, c'est ce comportement qui le permet.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 08 octobre 2014 à 15:57.
Je suis assez vieux pour avoir vu les magazines parler du PowerPC tueur d'Intel pour le grand public, par exemple. IBM y croyait à mort. Apple a mordu à la chose, avant d'en avoir marre, bizarre.
Je regarde juste les chiffres de vente d'Intel et d'IBM. Certes IBM joue sur sa marque, ça fait plaisir à du monde, mais c'est tout.
Ce qui est rigolo est de voir des pro-Linux me critiquer, alors que justement Linux a balayé… les autres Unix. HP-UX et compagnie ont des miètes. Comme les concurrent d'Intel.
Attaque personnelle, alors que je parle généralité. Indice qu'il y a un manque d'arguments.
tu n'as par contre pas répondu pour donner des exemples de la où on ne peut pas mettre 2 machines à la place d'une.
Désolé de ne pas avoir d'empathie envers les gens qui disent proposer sans rien proposer. J'ai demandé qu'on me parle de ratio performance/coût, parait que c'est interessant, mais sans jamais donner de chiffres. etonnant.
Si ça rapporte 1000 pour un cout de 100 alors que chez Intel le cout est de 50, désolé n'importe quel responsable financier te dira d'aller te faire voir avec ton truc à 100.
On s'en fout de combien ça rapporte, du moment où on compare la prestation équivalente (comprenant la gestion de pannes, c'est évident).
Le futur du PowerPC qui allait écraser Intel grace à la recherche des chez IBM, c'est bon je l'ai déjà lu il y a ~20 ans. Rendez-vous dans 20 ans pour refaire le point?
Il ne faut pas croire tous les chercheurs.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par lasher . Évalué à 2.
Sérieusement, je pense simplement que tu ne traites pas avec les services de (grosses) boites qui ont réellement besoin de ce genre de machines. Pas simplement dans le HPC (qui est réellement un monde à part, même si les petits clusters ont tendance à apparaître un peu partout), mais aussi pour certains traitements de données en quasi-temps réel et qui bénéficient grandement de ce genre de matériel. IBM est à ma connaissance le seul constructeur qui fasse de la R&D sérieuse sur les processeurs haute-performance (AMD essaie mais semble pas mal se planter : depuis Hyper-Transport, y'a des tentatives mais rien de convaincant) et qui soit capable de contrer Intel. Et oui, une grande partie de ces applications s'exécute loin des regards, dans des trucs genre DOD.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Y'a ARM aussi.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Larry Cow . Évalué à 1.
Oui, enfin à la différence d'une voiture, pour la plupart des tâches concernées deux machines à 50 valent une à 100.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . Évalué à 3.
Ouais enfin les analogies ont leurs limites hein… Si le but, c'est de transporter 4 tonne de marchandises et que pour le prix d'une Ferrari tu peux acheter 8 Golf Turbo, tu iras plus vite en faisant des aller-retours avec tes Golf Turbo qu'avec ta Ferrari.
En informatique, on arrive un peu à diviser les traitements en blocs indépendants, ce qui permet de les exécuter en parallèle. Alors si pour le même prix tu peux avoir 80 cœurs 40% moins puissances (au lieu de 10), bah ce sera quand même beaucoup beaucoup plus rapide sur tes 80 cœurs moins puissants.
Ok, les Power, c'est des belles machines. Mais quand tu fais rentrer le prix dans l'équation, ça devient plus compétitif du tout.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par karteum59 . Évalué à 5.
Les data-centers sont limités en énergie. Avoir une meilleure densité est logique lorsque la contrainte vient de l'espace/energie qu'on te fournit. Ce n'est pas pour rien que l'architecture ARM64 intéresse beaucoup de monde, et Intel a peut-être jugé que cette concurrence présentait un risque justifiant un effort prioritaire sur cet axe…
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . Évalué à 4.
C'est pas totalement vrai. C'est effectivement devenu difficile de monter en fréquence, par contre le nombre de cœurs par chip augmente à chaque génération (18 cœurs/36 threads par chip sur les Haswell-EP). La taille gérée par les intructions vectorielles augmente et de plus en plus d'opérations sont réalisables en vectoriel (SSE 128 bits -> AVX 256 bits, apparition du Fused-Multiply-Add avec AVX2 etc.). Les améliorations des micro-architectures apportent des gains assez faibles mais qui accumulés deviennent non-négligeables. Par exemple sur les caculs entiers, on a Haswell +10% (2013), Ivy Bridge +15% (2012), Sandy Bridge +27% (2011). Finalement le gain de performance par rapport à un Nehalem de 2009 atteint 60%. C'est pas énorme, mais pas négligeable non plus.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est justement le problème. Aucune application devient magiquement plus rapide avec du nouveau SIMD et de tout nouveau coeur, sans tout réécrire ou presque.
C'est le "assez" faible qui est gênant. A une époque, on avait le Pentuim 300Mhz qui est sorti après le 200Mhz (+50% de perf). Le nombre de cœur au delà de 4 devient presque inutile (sauf cas particulier), tant qu'il n'existera pas de langage qui distribue le boulot naturellement.
Sur du monothread entre un core 2 (2008/2010), et un core i7 il y a en moyenne 10 à 50% de performance en plus.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . Évalué à 2.
Mouais. Sur un serveur, la charge de travail se distribue quand même assez naturellement sur un certains nombre de cœurs, vu qu'un serveur fait plusieurs choses assez indépendantes en même temps. Typiquement, il va traiter plusieurs requêtes client en même temps. C'est assez facile de dispatcher les requêtes client sur un plus grand nombre de cœurs. Un serveur bénéficie "automatiquement" d'avoir 20 cœurs au lieu de 4.
Pour ce qui est du SIMD, l'auto-vectorisation dans les compilateurs (gcc, icc) commence à très bien marcher, donc une recompilation permet déjà d'obtenir un gain en performance.
De toutes façon, monter en fréquence c'est devenu physiquement impossible (la puissance dissipée augmente de manières quadratique par rapport à la fréquence) et c'est sur que ça devient plus difficile de gagner en performance.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Oui, mais c'est spécifique. En plus, J'imagine que l'augmentation de la vitesse décroit avec le nombre de cœur. Est-ce que 8 cœurs est vraiment 2x plus rapide que 4 ? La bande passante mémoire n'augmente pas aussi vite, idem pour les IO.
Vu que le code C impose le layout mémoire, sans le changer, j'ai de gros doute sur les accélérations possibles.
L'équation complète inclus la capacité parasite et la tension, qui peuvent toutes les 2 baisser. De plus, il pourrait rajouter des unités de calcul, j'imagine qu'une application bien écrit devrait tirer facilement des performances d'une unité de FPU de plus.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . Évalué à 3.
Bah ces gammes de processeurs (Xeon, Power8) s'adressent quand même vraiment au marché serveur. Du coup, c'est vraiment utile d'avoir un grand nombre de cœurs sur ce segment là.
Pour ce qui est de la bande passante mémoire, ça dépend effectivement de la workload. Si tu es memory bound, ça va pas t'avancer beaucoup d'avoir 8 cœurs au lieu de 4. Mais enfin si tu es memory bound un processeur à 4Ghz, ça ne sera pas plus rapide qu'un processeur à 2Ghz. Idem pour les I/O. En fait, la bande passante mémoire (et les I/O), c'est complètement orthogonal au problème de montée en fréquence vs. montée en nombre de cœurs.
Par exemple ça, gcc sait auto-vectoriser (donc speedup effectif de 6-8 sur un processeur gérant l'AVX):
Ça marche un peu moins bien quand tu as des opérations horizontales (ici le calcul de la somme globale n'est pas verticale) :
D'ailleurs c'est ce qu'on fait avec les unités de calcul vectorielles (SIMD), on prend plein de silicium pour faire plein d'opérations en parallèle. Plutôt que d'avoir une FPU de plus, what about une FPU qui sait faire 8 opérations en même temps ? ;)
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Parce que personne ne code naturellement avec des gros tableau alignés pour faire une addition.( En plus ce genre de code se fait étrangler par la mémoire.)
Prends une simple image 2D, avec la gestion des canaux de couleur, il y a peu de cas qui peut se faire accélérer sans changer le code (surtout avec la gestion des bords).
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . Évalué à 3.
À noter, l'unité vectorielle sur les processeurs Intel peut aussi faire 1 seule instruction à la fois (instructions se terminant en ss, pour single signed, par exemple vaddss). Gcc ne se prive d'ailleurs pas de l'utiliser de cette manière quand tu lui passes -ftree-vectorize (inclus dans -O3).
Et sur du code numérique, c'est quand même courant d'avoir des gros tableaux de flottants. Dans le cas général, évidemment, c'est pas forcément intéressant.
Effectivement si les données sont organisées selon un layout arrays-of-structures plutôt que structure-of-arrays, l'auto-vectorisation ne fonctionne pas actuellement (dans gcc au moins). À quand des compilateurs qui modifient automatiquement le layout mémoire ?
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par lasher . Évalué à 2.
À noter que aussi chez Intel que chez IBM, il y a de la recherche faite sur des « memory ISA », c'est-à-dire un jeu d'instruction pour gérer les motifs d'accès à la mémoire (genre accès « 2D », accès « stridé », etc.). C'est pas près de sortir, mais ça avance doucement…
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par lasher . Évalué à 3.
J'oubliais :
Jamais avec C ou C++, car le standard l'interdit (quoi que avec C11 ou C99 il y a moyen de déclarer un champ de type
char field[];qui pourra être précisé plus tard si je me souviens bien).En règle générale, tu peux passer par un outil de transformation de code qui fera du source-to-source, mais un compilateur qui obéit à la norme du C ou du C++ ne pourra sans doute jamais optimiser la disposition des champs dans une structure car cela irait contre la norme (et surtout ce ne serait pas portable—par exemple si tu as 2 machines différentes qui communiquent via le réseau, et qui doivent s'envoyer des bouts de tableau/structure).
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par barmic . Évalué à 3.
Pas vraiment. Il y a pas un écart de 40% entre 2 générations de CPU intel (10% au mieux) donc 40% c'est entre 3 et 4 générations de retard, soit 6 à 8 ans (je parle des générations pas des mises à jour qu'ils font chaque année qui ont plus un objectif commercial).
Perso je trouve que 6 ans dans le domaine c'est très très loin d'être négligeable.
Note je parle là de comparer la puissance au benchmark d'une puce face à une autre, pas de savoir laquelle est la plus pertinente.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
On est déjà à +40% entre 2010 et aujourd'hui en x86. Alors que Intel a mis le frein sur l'augmentation des performances.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par barmic . Évalué à 4.
Hum, je me suis peut être trompé, je ne regarde que pour de la gamme grand publique c'est peut être différent pour Xeon. Mais 4 ans c'est long (c'est le temps de renouvellement de certaines machines).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Les machines pro "lag" un peu avec les gammes grand publique.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par lasher . Évalué à 4.
Hum, 40% de moins, c'est 4 jours de calcul en moins pour obtenir une réponse pour simuler un modèle quelconque. Je ne suis pas du tout d'accord pour dire « juste derrière ». Dans le domaine de la haute performance (pas forcément calcul scientifique), 5 ou 10 % je suis d'accord c'est « négligeable », mais 40%, certainement pas.
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Regarder le monothread pour du HPC, c'est pas sérieux.
"La première sécurité est la liberté"
[^] # Re: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par BAud (site web personnel) . Évalué à 1.
cela doit être dû à l'historique d'utilisation du python2 par les chercheurs qui, par nature, n'ont pas une formation de programmeur ;-)
(je parle bien d'historique, ça a la vie dure… voire un passif)
# ça s'utilise en entreprise
Posté par Ecran Plat (site web personnel) . Évalué à 5.
Dire que j'ai changé mes deux as-400 ce printemps (pas les miens ceux de mon bosse= pour des power 7.
C'est rigolo l'as-400 (on devrait dire iseries) est une plate-forme que j'ai jamais aimé, mais il faut reconnaître c'est extrêmement stable et rapide, nous avons l'erp qui tourne dessus avec une base montreuse et la bestiole elle ne bronche pas (90 utilisateurs).
En fait si on avait un linux dessus ou un autre unix (pas ce truc qui est posix avec des commandes bizarre) ça me dérangerait pas trop.
Mais autrement j'ai aussi des bi-xeon 8 coeurs + 8 coeurs logique (soit 32 coeurs logique par machine) sous Debian 7 qui font tourner des kvm (windows server) et des openvz et la avec 120pc connecté dessus ils ne bronche pas du tout.
tous nos serveurs ont été changé ce printemps (ils avaient 3 ans (leasing)) pour les as-400 (power 7) on n'a pas vu de différence au niveau perf par contre pour les intel c'est le jour et la nuit.
# Essayer
Posté par Phil3556 . Évalué à 0.
Bonjour,
Si vous voulez essayer aller faire un tour sur http://labs.runabove.com/power8 c'est grauit le 1er mois.
Phil
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.