1.2.2 : Matériel cible

• Si on doit faire aussi bon usage que possible d'un matériel précis et connu à l'avance (comme sur les supercalculateurs), on gardera en tête les capacités de ce matériel-là lors de l'écriture et l'optimisation du programme, quitte à employer pour cela des techniques spécifiques à ce dernier (ex: vectorisation AVX-512 chez Intel, raytracing matériel chez NVidia) qui feront que le programme ne fonctionnera pas ou mal sur d'autres matériels qui ne nous intéressent pas. Cela pourra nous amener à aller jusqu'à choisir l'approche algorithmique en fonction du matériel qu'on cible.
• Si à l'inverse on part d'un niveau de performances bien défini à atteindre en consommant aussi peu de ressources matérielles que ressources que possible (comme dans les environnements cloud), on sera plutôt en train de se demander quelles parties du programme ne respectent pas la spécification sur un matériel donné et pourquoi, en essayant progressivement de se diriger vers un matériel moins performant parmi la base de matériels envisagés. La portabilité du code aura donc davantage d'importance, puisque le matériel est une variable d'ajustment.
• Si on se retrouve dans le cas le plus flou d'une application qui doit s'exécuter sur des matériels très variés et "aussi vite que possible" sur chacun (comme dans le cas de la grille WLCG ou des ordinateurs personnels), la portabilité deviendra un élément central du processus d'optimisation, et il sera particulièrement important de mener des analyses de performances et tester des optimisations sur une base de matériels aussi large que possible pour s'assurer qu'on a bien en vue les différents facteurs qui peuvent limiter la performance, et que ce qui est une amélioration nette pour un matériel n'est pas une régression trop grave pour un autre.