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 ×ばつ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é à 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 ×ばつ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 ».