ouais c'est le point que je n'ai pas bien précisé (j'avais pourtant mis du souligné autour de _prévu_ ) :
- à terme, dans le futur, d'après zdnet, il est conçu pour 3 petaflop en pointe
- à terme, il est conçu pour plus de 1 petaflop atteint en continu (la métrique étant sans doute le sens du vent :) de manière plus réaliste la capacité des applis à réclamer de la CPU).
Ce qui est ballot tout de même, c'est que la métrique semble rester la CPU alors que dans mon boulot c'est plutôt la RAM le facteur limitant : l'informatique de gestion (oops pardon, l'information technology) c'est beaucoup beaucoup de données à traiter (et des développeurs persuadés que tout charger en mémoire est la bonne manière d'optimiser /o\). Côté CPU, si plus de 20%-40% sont utilisés sur la journée en moyenne c'est que l'appli est consommatrice (et bien développée) ou alors qu'elle traite du XML :/.
Bien sûr, au niveau du système d'information, de ce que j'en ai vu, c'est malheureusement une logique "batch" qui perdure plutôt que d'essayer de lisser la charge par du fil de l'eau...
Mais bon, le coeur de cible de ces monstres semble plutôt être le calcul en force, l'indicateur de CPU n'est pas forcément inintéressant... (quoique traiter de gros volumes d'informations ne devrait pas trop leur faire peur si les I/O suivent).
[^] # Re: un petaflop en continu
Posté par BAud (site web personnel) . En réponse au journal BlueGene/P...enfin le petaflop !. Évalué à 3.
- à terme, dans le futur, d'après zdnet, il est conçu pour 3 petaflop en pointe
- à terme, il est conçu pour plus de 1 petaflop atteint en continu (la métrique étant sans doute le sens du vent :) de manière plus réaliste la capacité des applis à réclamer de la CPU).
Ce qui est ballot tout de même, c'est que la métrique semble rester la CPU alors que dans mon boulot c'est plutôt la RAM le facteur limitant : l'informatique de gestion (oops pardon, l'information technology) c'est beaucoup beaucoup de données à traiter (et des développeurs persuadés que tout charger en mémoire est la bonne manière d'optimiser /o\). Côté CPU, si plus de 20%-40% sont utilisés sur la journée en moyenne c'est que l'appli est consommatrice (et bien développée) ou alors qu'elle traite du XML :/.
Bien sûr, au niveau du système d'information, de ce que j'en ai vu, c'est malheureusement une logique "batch" qui perdure plutôt que d'essayer de lisser la charge par du fil de l'eau...
Mais bon, le coeur de cible de ces monstres semble plutôt être le calcul en force, l'indicateur de CPU n'est pas forcément inintéressant... (quoique traiter de gros volumes d'informations ne devrait pas trop leur faire peur si les I/O suivent).