Tu ne peux sans doute pas vivre du site, mais ça peut faire un sérieux complément financier. J'ai connu un étudiant qui avait fait un site sur un domaine particulier, avec quelques pubs, et ça lui a permis de partir en vacances chaque été.
En d'autres mots : dire que la pub donne un aspect néfaste à un site est sans doute une tautologie, de même que la pub à la télé ou à la radio est chiante, etc. Donc si tu n'as pas de pub sur le site, il reste peu de solutions pour faire du fric avec du libre-mais-aussi-gratuit :
Tu proposes un ensemble de services gratuits (au moins un), et d'autres payants. Si tu as un joli produit à proposer, alors il est possible que pour un tarif attractif tu trouves des clients.
Tu mets une « tirelire électronique » (paypal, flattr, etc.) sur ton site en disant aux gens que s'ils aiment tes services, ils peuvent te récompenser en payant un petit quelque chose.
Tu fais pas : tu fais payer un prix qui te semble raisonnable pour le service que tu proposes. Par exemple : tu proposes un prix relativement bas mais fixe chaque mois, et un prix variable en fonction du nombre d'utilisateurs (pour couvrir les frais de location du serveur et de la bande passante par exemple). Plus tu as d'utilisateurs, plus le prix variable baissera, mais finira par atteindre un « plateau bas » (car il y a un minimum de bande-passante par utilisateur à considérer).
Perso, j'aime bien l'approche Wikipedia qui fait une campagne chaque année jusqu'à ce qu'un objectif financier soit atteint. Bien entendu, ça marche d'autant mieux que le site est déjà extrêmement bien fourni en contenu (donc en « service »). Le site de Reddit fait un truc un peu équivalent en ayant un objectif financier journalier pour payer tout le monde (employés, serveurs, etc.).
Au-delà de ça, point de salut : la pub est malheureusement nécessaire si on veut faire des sous.
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.
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.
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).
Si la "bande passante" est de 64Bytes/cycle, j'imagine que le bus fait 64Bytes, non ?
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. ↩
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 ?
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).
À 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…
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.
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.
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.
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 :
0,5 cycle par mot de 64 bits (8 octets) pour un load (en utilisant SSE, car le bus est de 16 octets entre le cœur et le L1)
~0,8 cycle par mot de 64 bits pour accéder au L2
~1,2 cycle par mot de 64 bits pour accéder au L3
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.
Ça dépend fortement de quel pays on parle. En Australie / Nouvelle Zélande, on s'en fout un peu, et en fonction du milieu où on se trouve, en Irlande itou. Aux US et en GB, c'est aussi mauvais que « nigger » et considéré comme très misogyne (d'ailleurs ils parlent de « n-word » et « c-word » sur les chaînes qui blippent les mots1).
Ce que je trouve rigolo, c'est que « cunt » se traduit littéralement par con en Français (donc le vagin), et que chez nous il a complètement perdu son sens initial.
L’UE puis l’Allemagne ont activement et consciencieusement participé au démentèlement de la Grèce. Alors quelqu’un qui pense que l’UE n’a pas assez aidé la Grèce, ben ça me fait juste l’effet d’un extra-terrestre qui vient de débarquer sur Terre, c’est carrément surréaliste. Voir ce blog qui résume la question : http://www.greekcrisis.fr/
… C'est si difficile que ça ?
Dire que c'est surréaliste je trouve ça un peu fort par contre, car justement ce que j'essaie d'expliquer, c'est que dans un vrai état fédéral, même avec des états qui se font de la compèt' niveau maternelle, le gouvernement fédéral ne laisserait pas passer ce qui se passe en ce moment en Grèce, et encore moins ne poserait de mécanisme pour encourager son démantèlement (un état en faillite est un état qui ne rapporte plus de pognon pour le budget fédéral).
Concernant le lien avec le Cell BE — oui ça ressemble beaucoup, mais avec quelques grosses différences :
Les SPU du Cell BE avaient un scratchpad de 256 Kio, pour le code ET les données. Par contraste, C64 avait un cache d'instructions et le scratchpad et la SRAM n'étaient utiles que pour les données. Je l'ai déjà peut-être dit ici, mais un ingénieur d'une agence américaine à trois lettres bien aimée ici avait dit aux architectures présents dans la salle que le prochain à lui filer une architecture sans cache d'instruction, il le tabasserait.
Comme j'avais dit avant, la SRAM partagée suit le modèle SC (sequential consistency) grâce à son cross-bar. Ça veut dire entre autre que toute lecture ou écriture dans le « cache » / la SRAM (il y a en fait 30 bancs mémoire vers la SRAM) suivra un ordre total sans le surcoût d'un protocole de cohérence.
Pas de DMA engine (mais pas d'anneau pour communiquer entre les threads non plus, ce qui est un plus)
Instructions atomiques au niveau du contrôleur mémoire : fetch-and-add est en réalité plutôt un add-and-return-old-value, ce qui permet de faire de l'overlapping, contrairement à la sémantique du load-modify-write avec verrouillage de ligne de cache ou même du bus.
Après, évidemment il y a plein de soucis, du genre le malloc du 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.
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.
J’ai pas éludé. J’ai mis un lien. Lisez tous les billets de ce blog pendant quelques années, et vous vous rendrez compte pourquoi vous dites une grosse connerie. Et que vous récidivez.
Tu te rends compte de la condescendance de ton propos ? Tu balances un lien sans explication, et tu me dis que j'ai à me taper tous les billets contenu dans le site visé ? OK, la prochaine fois que quelqu'un pose une question sur un sujet que je prétends connaître, genre un truc sur l'architecture des processeurs ou la compil, je filerai vers un lien vers le papier qui décrit la technique dont on parle, et qui se trouve derrière un paywall. T'as pas payé ton dû à l'ACM ? Dommage, mais c'est tellement évident que je ne vais pas me prendre la tête à t'expliquer hein.
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).
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…).
Voilà, élude plutôt que m'expliquer en quoi tu n'es pas d'accord avec moi. En fait je suis certain que tu me prêtes des opinions que je n'ai pas, et donc t'as décidé de me foutre dans une case sans avoir au préalable vérifié que tu avais raison…
Ce que je disais à propos de l'Espagne et la Grèce dans ma note de bas de page c'est justement que l'UE ne fait pas grand chose pour aider des pays qui en ont bien besoin, là où aux USA ça ne serait pas accepté.
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. :-)
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.
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.
Depuis que les SSD existent, l'avantage des solutions "pro" de stockage tombent fortement.
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).
[à propos des machines du DOD] Tu parles du HPC là, non ? Basé sur plein de powerPC (100k) et non du POWER il me semble.
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 ».
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).
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: Rentabilité
Posté par lasher . En réponse au journal La publicité "propre" ça existe ?. Évalué à 7.
Tu ne peux sans doute pas vivre du site, mais ça peut faire un sérieux complément financier. J'ai connu un étudiant qui avait fait un site sur un domaine particulier, avec quelques pubs, et ça lui a permis de partir en vacances chaque été.
En d'autres mots : dire que la pub donne un aspect néfaste à un site est sans doute une tautologie, de même que la pub à la télé ou à la radio est chiante, etc. Donc si tu n'as pas de pub sur le site, il reste peu de solutions pour faire du fric avec du libre-mais-aussi-gratuit :
Perso, j'aime bien l'approche Wikipedia qui fait une campagne chaque année jusqu'à ce qu'un objectif financier soit atteint. Bien entendu, ça marche d'autant mieux que le site est déjà extrêmement bien fourni en contenu (donc en « service »). Le site de Reddit fait un truc un peu équivalent en ayant un objectif financier journalier pour payer tout le monde (employés, serveurs, etc.).
Au-delà de ça, point de salut : la pub est malheureusement nécessaire si on veut faire des sous.
[^] # Re: Power8 chez OVH
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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…
[^] # Re: Power8 chez OVH
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Site communautaire de connards
Posté par lasher . En réponse au journal GOL en a ras le bol des gogols !. Évalué à 3.
Il n'a peut-être pas de langage aussi fleuri que les deux autres, mais il peut cracher un venin très puissant…
[^] # Re: cunt
Posté par lasher . En réponse au journal GOL en a ras le bol des gogols !. Évalué à 2.
Ça fait partie du shtick de stand up. Et je suis sûr que ça lui permet d'occuper ses mains en même temps.
[^] # Re: Concentration?
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 2.
Location Consistency, un truc qui est principalement de la recherche.
[^] # Re: Concentration?
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Concentration?
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: cunt
Posté par lasher . En réponse au journal GOL en a ras le bol des gogols !. Évalué à 4.
Ça dépend fortement de quel pays on parle. En Australie / Nouvelle Zélande, on s'en fout un peu, et en fonction du milieu où on se trouve, en Irlande itou. Aux US et en GB, c'est aussi mauvais que « nigger » et considéré comme très misogyne (d'ailleurs ils parlent de « n-word » et « c-word » sur les chaînes qui blippent les mots1).
Ce que je trouve rigolo, c'est que « cunt » se traduit littéralement par con en Français (donc le vagin), et que chez nous il a complètement perdu son sens initial.
Voir à ce sujet l'hilarant sketch de Louis C.K. ↩
[^] # Re: Non, l'UE n'est pas un pays.
Posté par lasher . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 6.
Et donc écrire ceci :
… C'est si difficile que ça ?
Dire que c'est surréaliste je trouve ça un peu fort par contre, car justement ce que j'essaie d'expliquer, c'est que dans un vrai état fédéral, même avec des états qui se font de la compèt' niveau maternelle, le gouvernement fédéral ne laisserait pas passer ce qui se passe en ce moment en Grèce, et encore moins ne poserait de mécanisme pour encourager son démantèlement (un état en faillite est un état qui ne rapporte plus de pognon pour le budget fédéral).
[^] # Re: Concentration?
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Moi qui croyais suivre un site en français...
Posté par lasher . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 2.
Graou. Paris-Lille = 1h de TGV, et chez-moi-New York City, pour une distance relativement comparable, c'est ~2h30.
Voilà voilà.
[^] # Re: Non, l'UE n'est pas un pays.
Posté par lasher . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 7.
Tu te rends compte de la condescendance de ton propos ? Tu balances un lien sans explication, et tu me dis que j'ai à me taper tous les billets contenu dans le site visé ? OK, la prochaine fois que quelqu'un pose une question sur un sujet que je prétends connaître, genre un truc sur l'architecture des processeurs ou la compil, je filerai vers un lien vers le papier qui décrit la technique dont on parle, et qui se trouve derrière un paywall. T'as pas payé ton dû à l'ACM ? Dommage, mais c'est tellement évident que je ne vais pas me prendre la tête à t'expliquer hein.
[^] # Re: Concentration?
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Non !
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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, l'UE n'est pas un pays.
Posté par lasher . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 9.
Voilà, élude plutôt que m'expliquer en quoi tu n'es pas d'accord avec moi. En fait je suis certain que tu me prêtes des opinions que je n'ai pas, et donc t'as décidé de me foutre dans une case sans avoir au préalable vérifié que tu avais raison…
Ce que je disais à propos de l'Espagne et la Grèce dans ma note de bas de page c'est justement que l'UE ne fait pas grand chose pour aider des pays qui en ont bien besoin, là où aux USA ça ne serait pas accepté.
[^] # Re: Concentration?
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Non !
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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.