Réduire votre dette de performance logicielle à zéro en 3 étapes

Cet article présente l’approche que nous avons chez WedoLow pour détecter une dette de performance logicielle et la corriger. Une approche qui a permis à notre équipe de réduire le temps d’optimisation d’une application de traitement d’image de 4 semaines (2 ingénieurs à temps plein) en 10 minutes, tout en réduisant de 50% le temps d’exécution. Il explique comment une bonne combinaison de profilage de votre application logicielle et d’analyse liée au processeur peut être utilisée pour détecter la dette de performance logicielle et la résoudre automatiquement.

Au lieu de s’appuyer sur des outils de profilage imprécis, qui ne prennent pas en compte la cible matérielle sur laquelle le logiciel doit être exécuté, chez WedoLow, nous utilisons une combinaison de profilage utilisant une analyse dynamique ainsi qu’une analyse approfondie du code d’assemblage produit pour la cible matérielle considérée.

Conseil 💡 il vaut mieux envoyer dès maintenant à votre équipe de développement de logiciels embarqués une copie de cet article !

Prêt à découvrir comment on procède chez WedoLow ?
Restez avec nous, on va tout vous expliquer ⬇️

• Qu’est-ce qui prend du temps dans votre application ?
• Passez-vous du temps à traiter des données (opérations mathématiques), à effectuer des opérations de mémoire (chargement, stockage…) ou des opérations de contrôle ?
• Est-ce cohérent par rapport à ce que vous êtes censé faire dans votre application ?

Un profileur vous aidera à savoir ce qui se passe dans votre application, mais à un niveau très grossier. Il vous aidera à comprendre où se trouvent les goulots d’étranglement dans votre application, mais pas à déterminer si votre application passe le plus clair de son temps à faire ce qu’elle doit faire. Pour le savoir, il faut faire le lien entre elle et le matériel qui l’exécutera (Hello le code assembleur !).

Une fois que vous avez compris ce qui se trouve dans votre application logicielle, il est temps de comprendre quel est votre goulot d’étranglement en matière de performances. Pour cela, un bon outil de profilage peut être utilisé et peut produire des résultats :
→ un graphe d’appel (call graph)
→ un graphique de flammes (flame graph)

Si vous souhaitez en savoir plus sur les différentes techniques de profilage ou sur les différences entre un graphe d’appel et un graphique de flammes ➡️ parlez avec nos experts !

Si vous savez où vous passez du temps dans votre application, vous devez y travailler.

Si vous vous concentrez sur des parties insignifiantes de la consommation de temps pour détecter la dette de performance ou l’optimiser, alors même un gain énorme n’aura pas assez d’impact pour être vu dans la vie réelle de votre application.

Choisissez votre bataille !

L’analyse statique est géniale… mais si vous ne liez pas votre logiciel à votre cible matérielle, les informations que vous obtiendrez sur les performances ne seront absolument pas corrélées à votre exécution réelle.

Si la mesure qui doit être suivie est la performance, elle n’est pas lisible en utilisant uniquement le code source C/C++. Elle doit être enrichie d’informations sur l’assemblage et si possible, d’un profilage. Même avec des outils d’analyse statique performants, le suivi des performances manquera d’informations. Le risque ? Obtenir des recommandations qui ne seraient pas adaptées à votre cas d’utilisation spécifique.

Pour résoudre ce problème, une technique d’analyse statique enrichie d’informations sur l’assemblage et le profilage est essentielle. Ensuite, plusieurs informations (que nous appelons « techniques d’optimisation ») peuvent être trackées pour vérifier si votre application logicielle n’a pas de dette de performance par rapport à votre cible matérielle. Quelques exemples ci-dessous :

• utilisation correcte des types de données
• vectorisation (y a-t-il des zones possibles qui pourraient être vectorisées, mais qui ne le sont pas automatiquement par le compilateur ?)
• utilisation correcte des instructions de l’architecture du jeu d’instructions de votre processeur

La mesure et le suivi de la dette de performance et de la complexité de votre application logicielle doivent être effectués le plus tôt possible dans le processus de développement. En effet, cela a un impact sur de nombreux aspects :

• la manière dont vous concevrez un algorithme (et choisirez entre différentes structures de filtres, par exemple)
• le choix de la qualité à la sortie de votre application logicielle (en fonction de la performance obtenue, la qualité peut être échangée pour favoriser la performance en implémentant certaines approximations, en réduisant la largeur de bit de certaines données…)
• le choix de la cible matérielle (la charge du processeur, la mémoire… ont un impact sur le choix de la cible matérielle. S’ils sont connus très tôt dans le processus, ils peuvent aider à arbitrer entre différents processeurs).

De nombreux ingénieurs logiciels pensent qu’ils doivent aborder la question de la performance et de son optimisation à la fin du processus de développement. Il est généralement trop tard, et le risque est d’avoir un algorithme de haut niveau très puissant et donnant une qualité de sortie élevée, tout en étant impossible à intégrer sur la cible matérielle choisie. Les boucles de rétroaction infinies entre les équipes matérielles et logicielles, ça vous dit quelque chose ?

Si vous suivez ce processus, il vous guidera et vous aidera à suivre l’évolution de la complexité de votre application logicielle ainsi qu’à mesurer votre dette de performance.

J’espère que ce guide vous a été utile ! N’hésitez pas à me faire part de vos réflexions et peut-être de vos propres conseils à ce sujet.

 ➡️ Passez à l’action en réDuisant votre dette de performance logicielle à zéro !