En fonction de votre cible (voir la figure plus bas), nous fournissons différents niveaux d’optimisation. En revanche, tous les objectifs ne sont pas indépendants. Par exemple, l’optimisation apportée ciblant les superordinateurs bénéficie généralement également aux clusters et, a un niveau moindre, aux ordinateurs de bureau suffisamment performants. De façon similaire les applications destinées à l’internet des objets (I.O.T.) sont souvent préparées sur des plateformes embarquées à des fins de test. Récemment, des solutions unifiées d’optimisation sur plusieurs plateformes ont été développées et utilisées avec succès. Néanmoins, à OVHPA – High Performance Applications, nous pensons qu’il y a toujours un bénéfice à optimiser chaque cible individuellement.
Tout d’abord, l’optimisation des performances d’une application sur une architecture donnée, va dépendre de façon explicite de ce choix de matériel. Pour les superordinateurs ainsi que les clusters, cela signifie que, non seulement le processeur (CPU) et de ses éventuels composant vectoriels comme les processeurs graphiques (GPUs), mais aussi la technologie d’interconnexion et sa topologie de réseau sont d’une importance critique. Pour les ordinateurs ordinaires et les cibles plus petites, la technologie de réseau peut être moins importante. L’utilisation de cibles telles que les microcontrôleurs ou les applications destinées à l’internet des objets doivent en compromis échanger de la performance contre une taille de code inférieure, qui deviendra le facteur prépondérant de l’optimisation, tandis que pour ces architectures, le code résultant n’est souvent pas portable.
Un autre aspect important est la sécurité de l’application. Pour les superordinateurs et les clusters, cette sécurité est souvent dispensée à l’échelle du système tout entier. Cela veut dire que, pour des applications orientées performance qui vont s’exécuter sur ces cibles, la seule mesure de sécurité va être de rester à jour de toutes les dépendances, bibliothèques logicielles ou codes tiers. Pour les ordinateurs de bureau, cible traditionnelle des attaques informatiques, la sécurité doit être à la mesure des ressources et privilèges auxquels l’application aura accès. En fonction du système d’exploitation, certaines solutions générales existent (par exemple les sandbox) mais ces solutions ne sauraient remplacer un audit en règle du code de vos applications. Alors que les imprimantes et les téléphones portable font l’objet d’un nombre croissant d’attaques informatiques, il paraît probable que le centre d’intérêt de ces attaques va se porter sur les systèmes embarqués et I.O.T. Il y a beaucoup de raison pour cela, mais une des plus importantes est que les utilisateurs n’envisagent généralement pas ces systèmes comme des sujets de préoccupation au niveau de la sécurité. Il est aisé de comprendre qu’une box internet puisse être la cible d’attaque, mais qui va se méfier de la montre ou la brosse à dent connectée ? Pourtant ces objets connectés sont des moyens potentiels réels de subtiliser des données bancaires ou un mot de passe wifi. C’est pourquoi il est toujours important de planifier les capacités de votre application en fonction de ses besoins : votre système I.O.T. a-t-il réellement besoin de transmettre des données à une autre application, et si oui lesquelles ? Devons-nous stocker les mots de passes sur l’appareil ou utiliser des signatures, comment stocker les clefs de chiffrement sur un espace limité ? Pour ces systèmes toutes ces questions doivent trouver une réponse avant même de passer à l’étape du code.
Dans tous les cas, nous, à OVHPA – High Performance Applications, pensons que la plus importante des étapes pour produire une application sure et optimisée est d’inspecter intensément et régulièrement son code :
- en produisant un code clair et sans ambiguïté, si possible en utilisant des langages déclaratifs comme le C ou le Fortran, et avec une documentation exhaustive ;
- en utilisant des directives d’optimisation claires (et documentées), en séparant autant que possible les différentes plateformes cibles ;
- en ne liant l’application qu’à des bibliothèques logicielles nécessaires, et en utilisant seulement les plus établies et les plus régulièrement maintenues ;
- en effectuant de nombreux tests avec des utilisateurs différents, certains n’ayant que peu ou pas de connaissances du fonctionnement de l’application.
En essayant de maintenir ces directives simples, et en ayant un support initial réactif, votre application ne sera pas seulement optimisée et sure, elle sera reconnue pour cela.
Choisir une architecture cible a de nombreuses conséquences