L’objectif avoué de l’utilisation d’un serveur de calcul est d’obtenir des performances, ou plus exactement des accélérations enterme de temps de calcul. Les néophytes dans le domaine — et il n’y a aucune honte à celà — s’attendent souvent à ce qu’utiliser une »grosse machine » suffise pour obtenir des performances. C’est malheureusement plus compliqué.
Déporter ses calculs
Si l’on désire simplement exécuter en même temps de nombreuses instances d’un même code en faisant varier les paramètres, les nombreux noeuds de calcul d’Osaka répondront parfaitement à ce besoin. Le gain en temps de calcul sera énorme, puisqu’au lieu de les exécuter un par un sur une machine personnelle, on les exécutera par centaines en même temps.
Accélérer ses calculs
Si l’on désire réduire le temps de calcul d’un job (ou de plusieurs centaines), il sera nécessaire 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écessaire de modifier le code source. Ces modifications peuvent être plus ou moins grandes — en terme de lignes de code –, et plus ou moins techniques :
- corrections de maladresses et/ou d’ambiguités syntaxiques,
- ajout de directives de compilation,
- modification de l’algorithme afin de le paralléliser,
- changement d’algorithme et/ou de structure de données.
Toutes ces modifications sont ce que l’on appelle des optimisations. Dans tous les cas, plus on désire obtenir de performances, plus les changements du code source seront radicaux. Et au bout du compte, on cherchera à s’adapter au plus près des spécifications techniques de la machine sur laquelle on travaille.
De façon générale, lorsque l’on parle d’optimisation, on se doit de préciser le critère d’optimisation. En effet, dans un domaine donné (informatique, fiscalité, administration, …), il n’y a rarement qu’un seul critère pouvant être amélioré, et ces différents critères peuvent être incompatibles entre eux. Dans le cas d’un code de calcul, on peut bien sûr optimiser le temps de calcul, mais aussi la taille mémoire de l’exécutable, l’empreinte mémoire de l’exécution, ou même encore la consommation d’énergie. Dans le cadre du HPC (High Performance Computing), on s’intéresse le plus souvent au temps de calcul (à tel point qu’on omet de le préciser), et ce au détriment (le plus souvent) des autres critères d’optimisation.
Limites de l’optimisation
Lorsque les optimisations du code sont au plus près des spécifications 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 à nouveau faire cet effort d’adaptation. Il s’agit donc de pondérer les efforts déployés — qui peuvent être considérables — avec l’objectif à long terme.
- Si l’objectif principal est la performance — en supposant que le code soit déjà testé et éprouvé — alors ces efforts valent le coup. On parlera dans ce cas de code en état de production.
- Si au contraire le code est un prototype, dont la méthode peut être abandonnée au profit d’une autre à tout moment, le degré d’optimisation et d’efforts associés doivent être soigneusement pesés.
Un autre paramètre fondamental à considérer est la lisibilité du code source. Des optimisations poussées vont très souvent rendre un code incompréhensible (bien que l’inverse soit parfois vrai). Or un code de recherche a un devoir de transmission. Il est presque toujours amené à être repris : par le futur soit, par des étudiants, par d’autres chercheurs, etc… Il n’est ainsi pas rare d’abandonner des accélérations potentielles supplémentaires pour conserver un code lisible et conceptuellement cohérent. Placer la limite est très subjectif, mais il faut au moins avoir en tête cette problématique.