Je sais pas pour toi, mais les quelques codes de calculs parallèles sur lesquels je me suis penché (sans avoir la prétention d'en avoir écrit un) me semblent bien adaptés au passage à la GRANDE échelle. C'est pour moi la grosse différence entre des codes de calculs de simulation et des serveurs d'applications, donc la différence entre des SuperCalculateurs et des datacenters : le caractère physique du problème traité fait qu'il est "facilement" parallélisable.
Les codes auxquels je pense sont essentiellement des codes d'aérodynamique, c'est à dire de calcul d'écoulements d'air autour d'un objet (un avion, une voiture, un aspirateur etc...) Le mode de parallélisation est géométrique : on considére le domaine de calcul (e.g. un cube de 10m de côté) et on subdivise ce domaine en sous domaines (10'000 petits cubes de 10cm de côté) Chaque sous domaine est alors confié à un core (ou un CPU ou un noeud...)
Ca, c'est la partie facile. Il faut maintenant savoir que le code de calcul est itératif i.e. il affine une solution de calcul au fur et à mesure. Cet affinage se fait en échangeant les valeurs aux limites entre un sous-domaine donné et ses voisins. C'est cet échange de données qui est le gros problème : cela représente un gros débit de données, d'autant plus que le domaine est subdivisé. D'où l'intérêt des solutions de type InfiniBand à faible latence : la faible latence étant préférable au débit global, car on échange surtout des petites données très fréquemment. Sur certaines configurations (souvenir de Power6 IBM notamment) les switches InfiniBand sont d'ailleurs plus consommatrice de volume dans les racks que les noeuds de calculS.
Maintenant ça c'est juste de la théorie : le maillage du domaine de calcul n'est évidemment un cube géométrique subdivisé (l'avion n'est pas fait en Lego) les échanges de données demandent un gros boulot de synchro pour assurer la convergence du calcul... Voilà (pour revenir sur la discussion de mon journal) l'intérêt de maîtriser l'intégrateur pour pouvoir faire coller le HW aux besoins logiciels (nombre de core par noeud, quantité de RAM, bande-passante...)
[^] # Re: Classement sur des vrais calculs
Posté par tom120934 . En réponse à la dépêche Le classement Top 500 de juin 2010 est disponible. Évalué à 10.
Les codes auxquels je pense sont essentiellement des codes d'aérodynamique, c'est à dire de calcul d'écoulements d'air autour d'un objet (un avion, une voiture, un aspirateur etc...) Le mode de parallélisation est géométrique : on considére le domaine de calcul (e.g. un cube de 10m de côté) et on subdivise ce domaine en sous domaines (10'000 petits cubes de 10cm de côté) Chaque sous domaine est alors confié à un core (ou un CPU ou un noeud...)
Ca, c'est la partie facile. Il faut maintenant savoir que le code de calcul est itératif i.e. il affine une solution de calcul au fur et à mesure. Cet affinage se fait en échangeant les valeurs aux limites entre un sous-domaine donné et ses voisins. C'est cet échange de données qui est le gros problème : cela représente un gros débit de données, d'autant plus que le domaine est subdivisé. D'où l'intérêt des solutions de type InfiniBand à faible latence : la faible latence étant préférable au débit global, car on échange surtout des petites données très fréquemment. Sur certaines configurations (souvenir de Power6 IBM notamment) les switches InfiniBand sont d'ailleurs plus consommatrice de volume dans les racks que les noeuds de calculS.
Maintenant ça c'est juste de la théorie : le maillage du domaine de calcul n'est évidemment un cube géométrique subdivisé (l'avion n'est pas fait en Lego) les échanges de données demandent un gros boulot de synchro pour assurer la convergence du calcul... Voilà (pour revenir sur la discussion de mon journal) l'intérêt de maîtriser l'intégrateur pour pouvoir faire coller le HW aux besoins logiciels (nombre de core par noeud, quantité de RAM, bande-passante...)