La plupart des variétés de Linux de nos jours. Cependant, il existe une école de pensée selon laquelle les nœuds de calcul devraient exécuter des OS dépouillés, afin qu'ils ne gênent pas autant les applications. L'un d'entre eux est "Compute Node Linux".
Les programmes HPC, qui sont appelés "codes" par les initiés, ont tendance à ne pas beaucoup utiliser le système d'exploitation. Ils peuvent lire ou écrire des fichiers, généralement à partir de systèmes de fichiers hautement parallèles, et ils font certainement des entrées/sorties réseau, mais l'attitude du programmeur d'application HPC typique à l'égard du système d'exploitation est la suivante : " mappez-moi toute la mémoire, donnez-moi un accès direct à l'interface d'interconnexion, et ensuite restez hors de mon chemin "
Il existe un phénomène dans le HPC appelé " interférence du système d'exploitation ". Supposons que le système d'exploitation ait diverses tâches ménagères qui s'exécutent pendant 0,001 seconde toutes les secondes environ. 0,1 % de frais généraux, rien de bien grave, non ? Supposons maintenant que l'application est un programme parallèle de 1000 nœuds qui doit coordonner la progression des nœuds une fois par seconde environ. Boum ! Quelque part dans le système, l'un des nœuds est TOUJOURS en train de déjeuner en faisant quelque chose ou autre. Peut-être en exécutant lpd. Qui sait ? Le résultat net est que 999 nœuds attendent le millième, et que cette surcharge de 0,1% est amplifiée 1000 fois ! La moitié de la puissance de calcul du cluster est perdue à cause de ce minuscule système d'exploitation. Il n'est pas étonnant que les programmeurs HPC détestent l'OS.
Un autre point sensible est le réseau. Dans un bon jour, la latence de bout en bout d'un saut Ethernet utilisant 10 Gbps Ethernet, est d'environ 5 microsecondes. C'est pour le HPC. Les adaptateurs et commutateurs Infiniband bien conçus atteignent couramment une latence inférieure à 1 microseconde. À ces vitesses, il est tout simplement trop long d'appeler le système d'exploitation pour envoyer ou recevoir un paquet. Au lieu de cela, les réseaux HPC utilisent souvent le "contournement du système d'exploitation" dans lequel l'application (ou plus probablement une bibliothèque en mode utilisateur) peut parler directement à l'adaptateur E/S. La longueur du chemin logiciel entre l'application appelant SEND et les bits sur le fil est souvent inférieure à 200 instructions machine. Cela ne peut tout simplement pas être fait avec le système d'exploitation en travers du chemin. Même le codage des trames Ethernet est si mauvais pour la latence qu'il a tendance à rendre les ingénieurs HPC grognons. Des codes 64/66 ? Yechh.
Et ne me lancez pas sur la mémoire virtuelle. Chaque fois que quelqu'un dit "virtuel", vous devriez penser "lent".