Après avoir comparer les CPUs par cœur, on va comparer les puissances en utilisant la puissance maximale des alimentations…
Déjà si on compare les TDP des composants, c'est un peu plus réaliste.
Ce qui va consommer dans ton infra, c'est la tripotée de disques et les processeurs. En mettant que tu mets les mêmes disques dans le microcloud et les 3 serveurs classiques, le principal élément discriminant seront les processeurs :
Les cartes mères Bi-Xeon vont certes consommer plus que les petites cartes mères Opteron, mais 3 cartes mères, ça va forcément moins consommer que 12 (!).
Trois blocs d'alims de 800W, ça consommera plus que 1 bloc de 1600W, mais bon dans une infra un peu critique, je préfère avoir 6 alims que 2, vu que ça a quand même tendance a pas mal lacher…
Honnêtement pour faire efficace énergétiquement, multiplier les machines et les cœurs, c'est rarement la bonne solution.
La solution la plus simple et économique est peut-être quelque chose comme 3 serveurs à 7000€. Deux serveurs pour le calcul et les données "chaudes" en cours de traitement, avec beaucoup de RAM et de CPU et ~20To de stockage local chacun. On ajoute un troisième serveur avec peu de RAM et de CPU (Un quad core, et 32G) supportant des disques 3.5" pour le stockage froid (données pas en cours de traitement). Ou trois serveurs identiques.
Une remarque également sur les codes à effacement, qui tu sembles vouloir utiliser pour réduire la quantité d'espace de ton cluster dédiée à la tolérance aux pannes.
Certains codes (Reed-solomon notamment) sont dit systématiques, ce qui signifie qu'un fichier encodé en Reed-solomon peut être lu directement, sans décodage. Un décodage est seulement nécessaire lorsqu'il faut réparer (ie, récupérer) le fichier suite à la panne d'un disque.
D'autres codes (notamment la transformée mojette utilisée par RozoFS) sont non-systématiques, ce qui signifie qu'un fichier encodé en RozoFS doit être décodé avant de pouvoir être utilisé. Un décodage est également nécessaire pour réparer le fichier suite à la panne d'un disque. Le décodage consomme du temps CPU (de la puissance de calcul), ce qui peut être un problème (ou non, en fonction de ta worload).
Des quelques démo que j'ai vu, RozoFS a de bonnes performances voir très bonnes, c'est à dire que le décodage consomme peu de puissance CPU, mais peut-être qu'un code systématique serait mieux dans ton cas. Je sais pas exactement ou ça en est, mais les codes à effacement dont Reed-solomon (qui est systématique) sont en cours d'implémentation dans Ceph ( http://ceph.com/docs/giant/dev/erasure-coded-pool/http://ceph.com/releases/v0-80-firefly-released/ ).
Je te conseille de :
1. Vérifier que RozoFS ne mange pas trop de CPU, et fournit une bande passante suffisante. Si c'est le cas, aucun problème, tu devrais pouvoir l'utiliser. Il me semble que c'est un produit assez mature.
2. Sinon, regarde du coté de Ceph avec un Erasure Coded Backend (Reed-Solomon). La bande passante et la consommation CPU seront excellentes, par contre c'est peut-être un peu plus bêta/un peu moins mature.
Déjà, je sais pas ce que c'est que cette manie de mesurer la puissance de calcul en nombre de cœurs et de considérer que tout est équivalent. C'est sûrement valable quand on fait de l'hébergement web avec un CPU utilisé à 10% tout le temps, mais dès que le code est un peu calculatoire, il va y avoir des différences énormes entre un cœur de Core i5-4250U, un cœur de Xeon E5-2690v3 et un cœur d'Opteron 3380.
Typiquement un Opteron 3380 8 Cœurs (2.6-3.6 Ghz) est moins puissant qu'un tout petit Intel Xeon E3-1225v3 4 Cœurs (3.1Ghz - 3.5Ghz). Et quelle idée de venir comparer un core de Core i5-4250U 2C (1.3-2.6Ghz) a tout ça.
T'as l'air d'avoir de gros besoins en stockage (140 To, erf), et assez peut en CPU, mais quand même.
Aussi du matériel grand public (des NUCs) n'est pas prévu pour tourner 24h/24h dans un datacenter, tu vas avoir un taux de panne super élevé.
Pour information, la pub à droite était la même sur toutes les tablettes (y compris sur les quelques tablettes vraiment équipées d'Atom), et la partie gauche de l'écran affichait les information système exactes sur toutes les tablettes.
Bah ça dépend en fait. En général trolling et harcèlement c'est complètement décorrélé. Mais par exemple, toi, quand tu trolles, ça vire parfois au harcèlement.
PS : C'est de l'humour, second dégré, tout ça, hein. Porte pas plainte pour harcèlement
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/cpuinfo donne des cœurs cadencés à ~3Ghz.
Sur la 2XL :
$ uname -a
Linux power8 3.14.17-100.fc19.ppc64p7 #1 SMP Sat Aug 23 04:01:55 UTC 2014 ppc64 ppc64 ppc64 GNU/Linux
$ cat /proc/cpuinfo
processor : 0
cpu : POWER8E (raw), altivec supported
clock : 3026.000000MHz
revision : 2.1 (pvr 004b 0201)
[...]
processor : 175
cpu : POWER8E (raw), altivec supported
clock : 3026.000000MHz
revision : 2.1 (pvr 004b 0201)
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.
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/
Actuellement, tu prends 16 ops en un seul cycle. L'avx date de quand ? 2 ans max.
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.
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.
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.
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.
avant tu avais une seul multiplication même en SSE.
L'intructions MULPS (multiplication de 4 flottants en une seule instruction) est incluse dans le jeu d'instruction SSE qui date du… Pentium III.
le SIMD 512 bits, efficace c'est récent
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.
Il y a tout de même plus de contraintes d'utiliser du SIMD large par rapport à des GPU (un comble)
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…
On ne parle pas de la même chose. Je parle de latence, tu parles de bande-passante. :)
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.
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
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.)
À 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.
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).
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 ?
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.
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.
Sur un serveur, la charge de travail se distribue quand même assez naturellement sur un certains nombre de cœurs,
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.
Vu que le code C impose le layout mémoire, sans le changer, j'ai de gros doute sur les accélérations possibles.
Par exemple ça, gcc sait auto-vectoriser (donc speedup effectif de 6-8 sur un processeur gérant l'AVX):
float* a = malloc(gros tableau)
float* b = malloc(gros tableau)
float* c = malloc(gros tableau)
for(int i = 0; i < n) {
a[i] = b[i] + (c[i]*2);
}
Ça marche un peu moins bien quand tu as des opérations horizontales (ici le calcul de la somme globale n'est pas verticale) :
float* a = malloc(gros tableau)
float* b = malloc(gros tableau)
float sum;
for(int i = 0; i < n) {
sum += b[i] + (c[i]*2);
}
De plus, il pourrait rajouter des unités de calcul
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 ? ;)
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.
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é :
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.
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.
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.
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.
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.
Mais aujourd'hui, avec les SSD sur port PCI, j'ai un doute.
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.
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é.
Bon, on y va pour les coléoptères. Du logiciel, y'en a partout, même dans ton CPU Intel, il y a du microcode, c'est à dire du logiciel. Reste qu'à un moment, il faut bien tracer des limites entre les composants "matériels" et "logiciels" d'un ordinateur.
Même si ton CPU contient du logiciel (le microcode), tu seras d'accord pour admettre qu'il est complètement distinct du code de l'OS. Je peux changer d'OS (par exemple passer de Linux à FreeBSD), sans toucher au microcode de mon CPU. Je peux même même coder un OS sans avoir conscience du fait que le CPU utilise du microcode, parce que les OS utilisent une interface, en l'occurence l'ISA x86 dans le cas des CPU Intel, avec le CPU. On utilise généralement cette interface pour tracer la limite entre le logiciel et le matériel. Ce qui implémente l'interface, ici l'ISA x86 (le CPU) c'est du matériel, et ce qui utilise l'interface (l'OS), c'est du logiciel.
Pour revenir aux cas des mémoires flash et SSD, tu mélanges tout, vraiment tout. Un SSD, d'un point de vue interface, ce n'est pas de la mémoire flash. Un SSD, ça répond à des commandes SATA (qui constituent son interface), comme un disque dur classique. Et quand une commande SATA te demande de stocker un cluster, t'es censé le stocker de manière à peu près fiable (c'est à dire pas sous une forme qui disparaisse en deux semaines). Pour reprendre les concepts du paragraphe précédent, l'interface entre matériel (le SSD) et le logiciel (le filesystem), c'est les commandes SATA. Les filesystem classiques (ext2-3-4, xfs etc.) utilisent les commandes SATA, et le SSD implémente les commandes SATA. Donc dans le cas d'un SSD, tout ce qui est "gestion de la flash" (wear-leveling, gestion des cellules de mémoire) c'est implémenté en matériel. Parler du filesystem d'un SSD, ça ne veut rien dire, parce qu'on peut utiliser n'importe quel filesystem sur un SSD. C'est un peu comme parler de l'OS d'un processeur, ça n'a pas de sens.
Pour ne rien simplifier, il existe d'autres périphériques de stockages basés sur de la mémoire flash que les SSD, les MTD. l'interface entre matériel (la MTD) et le logiciel (le filesystem), ce n'est pas les commandes SATA. Ils implémentent une interface plus bas niveau pour le logiciel, ils exposent quasiment directement leurs cellules mémoires. C'est au logiciel, donc au filesystem d'effectuer la "gestion de la flash" (wear-leveling, gestion des cellules de mémoire). Des filesystem spécifiques ont étés développés pour les MTD : jffs2, ubifs, yaffs etc. On ne peut pas les utiliser sur un disque dur ni sur un SSD, parce qu'ils n'utilisent pas l'interface SATA mais une interface plus bas niveau spécifique aux MTD.
Pour encore plus complexifier, l'interface SATA (donc celle dont je parle deux paragraphes plus haut) a été un peu modifiée pour répondre aux besoins spécifiques des SSD (ben oui, c'est pas exactement la même chose qu'un disque dur même si on a pas eu envie de changer d'interface), c'est notamment le cas de la commande TRIM. F2FS est un filesystem utilisant l'interface SATA ainsi que les extensions pour les SSD (notamment TRIM). Il essaye aussi d'utiliser l'interface SATA de manière "accomodante" pour un SSD. Mais ça reste un filesystem utilisant l'interface SATA, donc pas pour les MTD.
Tout ça étant dit, je ré-insiste sur ma conclusion, parler du système de fichiers d'un SSD, ça n'a pas de sens ni même de "le logiciel de gestion du filesystem". Et ici, on parle bien d'un problème matériel, c'est bien au SSD de s'arranger pour qu'un cluster stocké ne soit pas perdu (un SSD n'est pas une MTD).
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. Évalué à 2.
Après avoir comparer les CPUs par cœur, on va comparer les puissances en utilisant la puissance maximale des alimentations…
Déjà si on compare les TDP des composants, c'est un peu plus réaliste.
Ce qui va consommer dans ton infra, c'est la tripotée de disques et les processeurs. En mettant que tu mets les mêmes disques dans le microcloud et les 3 serveurs classiques, le principal élément discriminant seront les processeurs :
12 Opterons 3380 : 12 * 65W = 780W
6 Xeons E5-2670v2 : 6 * 95W = 570W (-25%)
Les cartes mères Bi-Xeon vont certes consommer plus que les petites cartes mères Opteron, mais 3 cartes mères, ça va forcément moins consommer que 12 (!).
Trois blocs d'alims de 800W, ça consommera plus que 1 bloc de 1600W, mais bon dans une infra un peu critique, je préfère avoir 6 alims que 2, vu que ça a quand même tendance a pas mal lacher…
Honnêtement pour faire efficace énergétiquement, multiplier les machines et les cœurs, c'est rarement la bonne solution.
[^] # Re: Code à effacement, codes systématiques et puissance de calcul
Posté par X345 . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. Évalué à 1.
En fait, la question à se poser c'est est-ce que c'est une perte de 10% ou de 50% (bien pour ça qu'il faut bencher).
Regarde la charge CPU qu'il te faut pour lire à 100MB/s sur un disque, tu seras vite fixé.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. Évalué à 1.
Par exemple,
Actualis Power Store R3HTP4XFB-16 (7100€ HT)
2 Xeon E5-2650v2 (16 cœurs)
6x 16GB RAM (96GB RAM)
12 Western Digital SE 4TB (48TB)
T'en achètes 3 comme ça, ça te fait 21300€ HT (sans les cartes réseau) :
48 Cœurs Xeon Ivy Bridge 2.6Ghz
288 GB RAM (6Go/cœur)
144To Stockage
Si tu montes à 8000€ par nœud, tu peux avoir :
Actualis Power Store R3HTP4XFB-16 (8300€ HT)
2 Xeon E5-2670v2 (20 cœurs)
8x 16GB RAM (128GB RAM)
12 Western Digital SE 4TB (48TB)
Ce qui fait au total (25000€ HT)
60 Cœurs Xeon Ivy Bridge 2.5Ghz
384 GB RAM (6.4 Go/cœur)
144To Stockage
C'est surement les configurations le plus raisonnables.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. Évalué à 2.
La solution la plus simple et économique est peut-être quelque chose comme 3 serveurs à 7000€. Deux serveurs pour le calcul et les données "chaudes" en cours de traitement, avec beaucoup de RAM et de CPU et ~20To de stockage local chacun. On ajoute un troisième serveur avec peu de RAM et de CPU (Un quad core, et 32G) supportant des disques 3.5" pour le stockage froid (données pas en cours de traitement). Ou trois serveurs identiques.
Mais effectivement, ça fait un budget très serré.
# Code à effacement, codes systématiques et puissance de calcul
Posté par X345 . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. Évalué à 1.
Une remarque également sur les codes à effacement, qui tu sembles vouloir utiliser pour réduire la quantité d'espace de ton cluster dédiée à la tolérance aux pannes.
Certains codes (Reed-solomon notamment) sont dit systématiques, ce qui signifie qu'un fichier encodé en Reed-solomon peut être lu directement, sans décodage. Un décodage est seulement nécessaire lorsqu'il faut réparer (ie, récupérer) le fichier suite à la panne d'un disque.
D'autres codes (notamment la transformée mojette utilisée par RozoFS) sont non-systématiques, ce qui signifie qu'un fichier encodé en RozoFS doit être décodé avant de pouvoir être utilisé. Un décodage est également nécessaire pour réparer le fichier suite à la panne d'un disque. Le décodage consomme du temps CPU (de la puissance de calcul), ce qui peut être un problème (ou non, en fonction de ta worload).
Des quelques démo que j'ai vu, RozoFS a de bonnes performances voir très bonnes, c'est à dire que le décodage consomme peu de puissance CPU, mais peut-être qu'un code systématique serait mieux dans ton cas. Je sais pas exactement ou ça en est, mais les codes à effacement dont Reed-solomon (qui est systématique) sont en cours d'implémentation dans Ceph ( http://ceph.com/docs/giant/dev/erasure-coded-pool/ http://ceph.com/releases/v0-80-firefly-released/ ).
Je te conseille de :
1. Vérifier que RozoFS ne mange pas trop de CPU, et fournit une bande passante suffisante. Si c'est le cas, aucun problème, tu devrais pouvoir l'utiliser. Il me semble que c'est un produit assez mature.
2. Sinon, regarde du coté de Ceph avec un Erasure Coded Backend (Reed-Solomon). La bande passante et la consommation CPU seront excellentes, par contre c'est peut-être un peu plus bêta/un peu moins mature.
[^] # Re: NUC pour le calcul, plus noeuds de stockage
Posté par X345 . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. Évalué à 6.
Sérieusement des NUCs pour faire du calcul…
Déjà, je sais pas ce que c'est que cette manie de mesurer la puissance de calcul en nombre de cœurs et de considérer que tout est équivalent. C'est sûrement valable quand on fait de l'hébergement web avec un CPU utilisé à 10% tout le temps, mais dès que le code est un peu calculatoire, il va y avoir des différences énormes entre un cœur de Core i5-4250U, un cœur de Xeon E5-2690v3 et un cœur d'Opteron 3380.
Typiquement un Opteron 3380 8 Cœurs (2.6-3.6 Ghz) est moins puissant qu'un tout petit Intel Xeon E3-1225v3 4 Cœurs (3.1Ghz - 3.5Ghz). Et quelle idée de venir comparer un core de Core i5-4250U 2C (1.3-2.6Ghz) a tout ça.
T'as l'air d'avoir de gros besoins en stockage (140 To, erf), et assez peut en CPU, mais quand même.
Aussi du matériel grand public (des NUCs) n'est pas prévu pour tourner 24h/24h dans un datacenter, tu vas avoir un taux de panne super élevé.
# Sinon y'a Intel Atom ARM
Posté par X345 . En réponse au journal Intel leader sur tablettes Android ! Mon oeil !. Évalué à 6.
Vu dans une grande enseigne française d'ameublement, la tablette Intel Atom ARMv7 :
https://i.imgur.com/hlgQ2Zal.jpg
Pour information, la pub à droite était la même sur toutes les tablettes (y compris sur les quelques tablettes vraiment équipées d'Atom), et la partie gauche de l'écran affichait les information système exactes sur toutes les tablettes.
[^] # Re: WTF ?
Posté par X345 . En réponse au journal La chasse aux trolls est ouverte !. Évalué à 9.
Bah ça dépend en fait. En général trolling et harcèlement c'est complètement décorrélé. Mais par exemple, toi, quand tu trolles, ça vire parfois au harcèlement.
PS : C'est de l'humour, second dégré, tout ça, hein. Porte pas plainte pour harcèlement
[^] # Re: Power8 chez OVH
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Concentration?
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Concentration?
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Concentration?
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Ces architectures sont de plus en plus rares mais pas encore mortes
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: Concentration?
Posté par X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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 X345 . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. É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: F2FS ?
Posté par X345 . En réponse au journal SSD Samsung 840: le fiasco annoncé du TLC ?. Évalué à 10.
Bon, on y va pour les coléoptères. Du logiciel, y'en a partout, même dans ton CPU Intel, il y a du microcode, c'est à dire du logiciel. Reste qu'à un moment, il faut bien tracer des limites entre les composants "matériels" et "logiciels" d'un ordinateur.
Même si ton CPU contient du logiciel (le microcode), tu seras d'accord pour admettre qu'il est complètement distinct du code de l'OS. Je peux changer d'OS (par exemple passer de Linux à FreeBSD), sans toucher au microcode de mon CPU. Je peux même même coder un OS sans avoir conscience du fait que le CPU utilise du microcode, parce que les OS utilisent une interface, en l'occurence l'ISA x86 dans le cas des CPU Intel, avec le CPU. On utilise généralement cette interface pour tracer la limite entre le logiciel et le matériel. Ce qui implémente l'interface, ici l'ISA x86 (le CPU) c'est du matériel, et ce qui utilise l'interface (l'OS), c'est du logiciel.
Pour revenir aux cas des mémoires flash et SSD, tu mélanges tout, vraiment tout. Un SSD, d'un point de vue interface, ce n'est pas de la mémoire flash. Un SSD, ça répond à des commandes SATA (qui constituent son interface), comme un disque dur classique. Et quand une commande SATA te demande de stocker un cluster, t'es censé le stocker de manière à peu près fiable (c'est à dire pas sous une forme qui disparaisse en deux semaines). Pour reprendre les concepts du paragraphe précédent, l'interface entre matériel (le SSD) et le logiciel (le filesystem), c'est les commandes SATA. Les filesystem classiques (ext2-3-4, xfs etc.) utilisent les commandes SATA, et le SSD implémente les commandes SATA. Donc dans le cas d'un SSD, tout ce qui est "gestion de la flash" (wear-leveling, gestion des cellules de mémoire) c'est implémenté en matériel. Parler du filesystem d'un SSD, ça ne veut rien dire, parce qu'on peut utiliser n'importe quel filesystem sur un SSD. C'est un peu comme parler de l'OS d'un processeur, ça n'a pas de sens.
Pour ne rien simplifier, il existe d'autres périphériques de stockages basés sur de la mémoire flash que les SSD, les MTD. l'interface entre matériel (la MTD) et le logiciel (le filesystem), ce n'est pas les commandes SATA. Ils implémentent une interface plus bas niveau pour le logiciel, ils exposent quasiment directement leurs cellules mémoires. C'est au logiciel, donc au filesystem d'effectuer la "gestion de la flash" (wear-leveling, gestion des cellules de mémoire). Des filesystem spécifiques ont étés développés pour les MTD : jffs2, ubifs, yaffs etc. On ne peut pas les utiliser sur un disque dur ni sur un SSD, parce qu'ils n'utilisent pas l'interface SATA mais une interface plus bas niveau spécifique aux MTD.
Pour encore plus complexifier, l'interface SATA (donc celle dont je parle deux paragraphes plus haut) a été un peu modifiée pour répondre aux besoins spécifiques des SSD (ben oui, c'est pas exactement la même chose qu'un disque dur même si on a pas eu envie de changer d'interface), c'est notamment le cas de la commande TRIM. F2FS est un filesystem utilisant l'interface SATA ainsi que les extensions pour les SSD (notamment TRIM). Il essaye aussi d'utiliser l'interface SATA de manière "accomodante" pour un SSD. Mais ça reste un filesystem utilisant l'interface SATA, donc pas pour les MTD.
Tout ça étant dit, je ré-insiste sur ma conclusion, parler du système de fichiers d'un SSD, ça n'a pas de sens ni même de "le logiciel de gestion du filesystem". Et ici, on parle bien d'un problème matériel, c'est bien au SSD de s'arranger pour qu'un cluster stocké ne soit pas perdu (un SSD n'est pas une MTD).