La loi d’Amdahl

Pour cela, tournons-nous vers la loi d’Amdahl.

C’est l’augmentation maximale de vitesse que l’on peut obtenir en améliorant la performance d’une partie seulement d’un système. Dans notre cas, la loi peut être paraphrasée ainsi :

L’augmentation de la vitesse d’une application que l’optimisation peut fournir, est limitée par la fraction du temps d’exécution total que l’application passe dans le code optimisé.

Supposons une application qui effectue sa tâche en 1000 secondes sur une certaine série d’entrées. Et supposons que cette application passe 700 secondes à exécuter des appels système vers le système d’exploitation, et les 300 secondes restantes dans le code d’application proprement dit. Maintenant, supposons que vous recompiliez l’application en ajoutant l’optimisation. Par exemple, vous pourriez élever le niveau d’optimisation ou ajouter l’une des techniques d’optimisation avancées qui suivent dans cet article. Dans cet exemple, la technique d’optimisation améliore de 10 % la performance du code généré.

Quel est donc l’effet sur la performance de l’application ?

Comme l’amélioration ne s’applique qu’aux 300 secondes passées dans l’application, cette portion de l’application s’exécute maintenant en 270 secondes. L’intervalle de 700 secondes consacré à exécuter les appels système n’est pas affecté par l’optimisation du code de l’application, et donc reste inchangé. Par conséquent, l’application s’exécute maintenant en 970 secondes. Autrement, l’amélioration de 10 % du code applicatif se traduit par une amélioration de 3 % de la performance globale (à noter que si l’on inversait les contributions système et application, la performance de l’application serait améliorée de 7 %).

Cela signifie-t-il que vous ne devriez pas optimiser votre code si l’application passe le plus clair de son temps à faire des appels système ? Non. Comme le démontre cet exemple, l’optimisation peut encore produire des gains mesurables. Mais en sachant combien de temps votre application consacre à chaque processus, vous pouvez mieux déterminer les avantages produits par les diverses techniques d’optimisation.
Le meilleur moyen de voir où votre application passe son temps, est d’utiliser la fonction Profile Performance Explorer. Vous pouvez en savoir plus sur Performance Explorer dans l’IBM i Information Center.

Mesurer la performance

Si vous envisagez d’essayer différentes techniques d’optimisation, vous souhaiterez connaître la vitesse d’exécution de vos programmes. Certes, vous pourriez regarder l’application s’exécuter, chronomètre en main, mais ce ne serait ni fiable, ni satisfaisant, ni instructif.

Heureusement, il existe une meilleure méthode. À partir de la release 6.1, vous disposez de la commande  Analyze Command Performance (ANZCMDPRF) pour connaître la durée d’exécution de toute commande. Si une application peut être testée en appelant un programme unique, utilisez cette commande :

> ANZCMDPFR CMD(CALL applib/mypgm)
   ANZCMDPFR command completed successfully

À première vue, on ne voit pas bien l’intérêt de ce résultat. Mais si vous placez le curseur sur le message de bonne exécution (command completed successfully) et si vous appuyez sur F1, vous voyez s’afficher diverses statistiques sur la performance de l’application. À savoir : le temps que l’application a mis pour s’exécuter, le temps qu’elle a passé dans la CPU, et les types et quantités d’I/O effectués par le programme.

En exécutant ANZCMDPFR avant et après l’application des différents niveaux et techniques d’optimisation, vous verrez clairement les effets bénéfiques sur les performances.