Le côté hibernation empêche effectivement l’usage d’un fs réparti. D’un autre côté, on peut laisser tourner les bécanes, vu que le calcul de conso réel n’existe pas. Une machine éteinte ne nous fera rien gagner. Je sais c’est pas écolo etc. mais en divisant la conso finale par un bon 3 je pense que c’est déjà pas mal ;) Mais si, effectivement, on part sur du nas, autant éteindre les nœuds ne foutant rien.
Pour le GPU, comme je disais plus haut, nous avons beaucoup de codes existants, et parfois hérités, il est impossible pour nous de les réecrire en cuda ou opencl. de une, car cela serait très long à faire (passer du mono-thread au massivement parrallèle demande beaucoup de travail), qu’on est pas payé pour, et qu’on a pas non plus les moyens humains. De deux, parce que les clients ont besoin de codes fonctionnant au sein de leurs architectures existantes (et le spatial n’est pas vraiment un milieu se précipitant sur les nouvelles technos ;)).
Nous avons porté un code de type monte carlo (mono thread et en fortran siouplé) en gpu car nous étions financés. Cela a donné de bons résultats, et avons une machine s’occupant de ces calculs. Mais ça reste limité pour les raisons suscitées. On espère que ça va progresser, mais on y est pas encore...
[^] # Re: Type d'IO, Conso ?
Posté par laurent wandrebeck (site web personnel) . En réponse au message Remplacer un (petit) cluster pour consommer bcp moins tout en gardant de la puissance. Évalué à 1.
Le côté hibernation empêche effectivement l’usage d’un fs réparti. D’un autre côté, on peut laisser tourner les bécanes, vu que le calcul de conso réel n’existe pas. Une machine éteinte ne nous fera rien gagner. Je sais c’est pas écolo etc. mais en divisant la conso finale par un bon 3 je pense que c’est déjà pas mal ;) Mais si, effectivement, on part sur du nas, autant éteindre les nœuds ne foutant rien.
Pour le GPU, comme je disais plus haut, nous avons beaucoup de codes existants, et parfois hérités, il est impossible pour nous de les réecrire en cuda ou opencl. de une, car cela serait très long à faire (passer du mono-thread au massivement parrallèle demande beaucoup de travail), qu’on est pas payé pour, et qu’on a pas non plus les moyens humains. De deux, parce que les clients ont besoin de codes fonctionnant au sein de leurs architectures existantes (et le spatial n’est pas vraiment un milieu se précipitant sur les nouvelles technos ;)).
Nous avons porté un code de type monte carlo (mono thread et en fortran siouplé) en gpu car nous étions financés. Cela a donné de bons résultats, et avons une machine s’occupant de ces calculs. Mais ça reste limité pour les raisons suscitées. On espère que ça va progresser, mais on y est pas encore...