Quand un client (à qui on va livrer le code industrialisé pour qu’il se charge de la prod par exemple) a un cluster et nous dit que le code doit pas manger plus de x go en ram, et bien on s’arrange pour utiliser le max autorisé. Ce n’est pas plus compliqué que cela. Il est beaucoup plus facile de faire du monothread et de parralléliser sur les images que découper les images pour tout regrouper ensuite (encore pire quand il y’a une dépendance entre les pixels).
Les calculs ont tendance a être lourds, aussi, la partie I/O, même si elle est lourde, représente rarement (jamais ?) plus de la moitié du temps de processing. Si on n’utilise pas au max les CPU, on perd donc du temps.
Dans les cas où un code a besoin de beaucoup de ram (disons 28go), htcondor le pose sur une bécane pouvant l’encaisser, le cpu patauge tout ce qu’il peut et les autres cpu restent inutilisés (si le code est monothread) parce qu’ils n’ont plus/très peu de ram dispo et que les autres jobs veulent davantage que ce qui est disponible, auquel cas ils vaquent sur d’autres machines ou attendent que ça se libère.
Mais j’ai la désagréable impression de répondre à côté de la plaque ou d’avoir raté le point de ton commentaire.
[^] # 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.
Quand un client (à qui on va livrer le code industrialisé pour qu’il se charge de la prod par exemple) a un cluster et nous dit que le code doit pas manger plus de x go en ram, et bien on s’arrange pour utiliser le max autorisé. Ce n’est pas plus compliqué que cela. Il est beaucoup plus facile de faire du monothread et de parralléliser sur les images que découper les images pour tout regrouper ensuite (encore pire quand il y’a une dépendance entre les pixels).
Les calculs ont tendance a être lourds, aussi, la partie I/O, même si elle est lourde, représente rarement (jamais ?) plus de la moitié du temps de processing. Si on n’utilise pas au max les CPU, on perd donc du temps.
Dans les cas où un code a besoin de beaucoup de ram (disons 28go), htcondor le pose sur une bécane pouvant l’encaisser, le cpu patauge tout ce qu’il peut et les autres cpu restent inutilisés (si le code est monothread) parce qu’ils n’ont plus/très peu de ram dispo et que les autres jobs veulent davantage que ce qui est disponible, auquel cas ils vaquent sur d’autres machines ou attendent que ça se libère.
Mais j’ai la désagréable impression de répondre à côté de la plaque ou d’avoir raté le point de ton commentaire.