L’objectif avou\u00e9 de l’utilisation d’un serveur de calcul est d’obtenir des performances, ou plus exactement des acc\u00e9l\u00e9rations en terme de temps de calcul. Les n\u00e9ophytes dans le domaine — et il n’y a aucune honte \u00e0 cel\u00e0 — s’attendent souvent \u00e0 ce qu’utiliser une\u00a0\u00bbgrosse machine\u00a0\u00bb suffise pour obtenir des performances. C’est malheureusement plus compliqu\u00e9.<\/p>\n\n\n\n
Si l’on d\u00e9sire simplement ex\u00e9cuter en m\u00eame temps de nombreuses instances d’un m\u00eame code en faisant varier les param\u00e8tres, les nombreux noeuds de calcul d’Osaka r\u00e9pondront parfaitement \u00e0 ce besoin. Le gain en temps de calcul sera \u00e9norme, puisqu’au lieu de les ex\u00e9cuter un par un sur une machine personnelle, on les ex\u00e9cutera par centaines en m\u00eame temps. Voir les array jobs<\/a> pour ce type d\u2019utilisation.<\/p>\n\n\n\n Si l’on d\u00e9sire r\u00e9duire<\/em> le temps de calcul d’un job (ou de plusieurs centaines), il sera n\u00e9cessaire de modifier le programme. Pour obtenir de meilleures performances, on se doit au minimum de modifier le processus de compilation. Et le plus souvent, il sera n\u00e9cessaire de modifier le code source. Ces modifications peuvent \u00eatre plus ou moins grandes — en terme de lignes de code –, et plus ou moins techniques :<\/p>\n\n\n\n Toutes ces modifications sont ce que l’on appelle des optimisations1<\/a><\/sup>. Dans tous les cas, plus on d\u00e9sire obtenir de performances, plus les changements du code source seront radicaux. Et au bout du compte, on cherchera \u00e0 s’adapter au plus pr\u00e8s des sp\u00e9cifications techniques de la machine sur laquelle on travaille.<\/p>\n\n\n\n Lorsque les optimisations du code sont au plus pr\u00e8s des sp\u00e9cifications techniques de la machine, les performances sont maximales. Mais si l’on doit changer de machine (pour une raison ou pour une autre), il faudra \u00e0 nouveau faire cet effort d’adaptation. Il s’agit donc de pond\u00e9rer les efforts d\u00e9ploy\u00e9s<\/em> — qui peuvent \u00eatre consid\u00e9rables — avec l’objectif \u00e0 long terme. <\/p>\n\n\n\n Un autre param\u00e8tre fondamental \u00e0 consid\u00e9rer est la lisibilit\u00e9<\/em> du code source. Des optimisations pouss\u00e9es vont tr\u00e8s souvent rendre un code incompr\u00e9hensible (bien que l’inverse soit parfois vrai). Or un code de recherche a un devoir de transmission. Il est presque toujours amen\u00e9 \u00e0 \u00eatre repris : par le futur soit, par des \u00e9tudiants, par d’autres chercheurs, etc… Il n’est ainsi pas rare d’abandonner des acc\u00e9l\u00e9rations potentielles suppl\u00e9mentaires pour conserver un code lisible et conceptuellement coh\u00e9rent. Placer la limite est tr\u00e8s subjectif, mais il faut au moins avoir en t\u00eate cette probl\u00e9matique.<\/p>\n\n\n L’objectif avou\u00e9 de l’utilisation d’un serveur de calcul est d’obtenir des performances, ou plus exactement des acc\u00e9l\u00e9rations en terme de temps de calcul. Les n\u00e9ophytes dans le domaine — et il n’y a aucune honte \u00e0 cel\u00e0 — s’attendent souvent … Continuer la lecture Acc\u00e9l\u00e9rer ses calculs<\/h2>\n\n\n\n
\n
<\/blockquote>\n\n\n\n
Limites de l’optimisation<\/h2>\n\n\n\n
\n