Qt : l’influence du compilateur sur les performances

Lorsqu’on développe une application mutli-plateformes il est important de se poser la question des performances sur les plateformes ciblées. A machine égale, selon le compilateur utilisé les performances peuvent être multipliées par deux.

La question des performances peut se poser sous plusieurs angles, dont au moins les deux suivants :

  • La conception exige que les performances soient (à peu près ?) équivalentes sur n’importe quelle plateforme d’exécution.
  • La conception exige que les performances soient les plus importantes possible.

Le premier point est très complexe à concevoir, mais moins à implanter. Il suppose d’être capable de cadencer les opérations selon une performance absolue qui peut se mesurer à l’exécution, ce qui peut impliquer de ralentir l’exécution sur les plateformes les plus rapides.

Ce type de fonctionnement est rare, nous ne nous attarderons pas dessus.

Le second point est beaucoup plus courant : comment obtenir les meilleures performances sur la plateforme d’exécution ?

Les réponses sont multiples et commencent par une bonne conception et un bon codage, cela va sans dire. J’ai déjà publié plusieurs articles à ce sujet. Ce qui va nous intéresser particulièrement aujourd’hui est l’observation de l’impact du choix du compilateur.

En premier lieu, il convient de constater que le choix du compilateur dépend avant tout des API systèmes offertes par celui-ci. Si vous n’utilisez que les API fournies par Qt, vous n’aurez aucun problème de compatibilité. En revanche, si vous utilisez des API Win32 pour le WLAN par exemple, celles-ci peuvent ne pas être toutes disponibles dans minGW.

Je supposerai donc que vous ne développez qu’avec des API de Qt et que seule la question du compilateur se pose.

Périmètre et limites

Ma petite étude, sans prétention et avec un certain nombres d’approximations, vise à mettre en évidence l’impact du choix du compilateur sur les performances de l’application. Mes conclusions ne prendront en considération que les aspects les plus évidents, les différences entre compilateurs les moins sensibles seront donc ignorées.

De plus, j’ai souhaité mettre en évidence l’impact de la version de Qt utilisée pour la compilation et l’exécution. En l’occurence j’utilise une version libre de Qt, l’exécutable est donc lié dynamiquement avec les bibliothèques de Qt. Il faut noter ici que sous Windows, Qt est associé à une version spécifique de minGW et donc de GCC. Les performances d’une version de Qt à l’autre sont donc étroitement liées à celles du compilateur utilisé. Sous macOS cela n’est pas le cas.

La matrice de résultat affichée dans ce test ne comprend pas tous les résultats, mais uniquement les plus significatifs.

Je n’ai fait aucun test de performance pour les technologies liées à Qt Quick (initialisation, instanciation, affichage, exécution du code Javascript, etc).

Méthodologie

J’ai réalisé un petit programme très simple qui effectue une sorte de benchmarking sous plusieurs aspects :

  • L’instanciation
  • La destruction d’objets
  • La copie (profonde) d’objets
  • Le calcul mathématique
  • Les graphismes
  • Les appels de fonction
  • La run-loop
  • Les threads

Les environnements de développement utilisés sont les suivants :

  • Microsoft Visual C++ 15.0 et SDK 10.0 en 32 bits
  • Microsoft Visual C++ 15.0 (Visual Studio 2017) et SDK 10.0 en 64 bits
  • GCC (minGW) en 32 bits sous Windows 7 64 bits

Les versions de Qt testées sont :

  • Qt 5.4.2 avec MinGW 4.9.1 en 32 bits
  • Qt 5.10.0 avec MinGW 5.3.0 en 32 bits

Les plateformes d’exécution sont :

  • PC portable Dell Vostro avec 8 Go de RAM, un CPU Core i7-4900MQ à 2,8 GHz (8 coeurs), tournant sous Windows 7 64 bits.
Algorithmes

Voici une courte description des algorithmes codés pour ce test. Si vous le souhaitez, vous pouvez télécharger le code source et modifier ces algorithmes pour les adapter à vos besoins. N’hésitez pas à me communiquer vos améliorations et suggestions afin que je les intègre dans mon programme.

Partagez cet article !

Abonnez-vous à notre newsletter !

Si vous souhaitez être notifié lorsqu'un nouvel article est publié, abonnez-vous à notre newsletter et vous recevrez un email dès qu'un article sera publié.

Pages : 1 2 3 4

Articles similaires

Utiliser la technique du ... Le lazy-loading, ou chargement paresseux en français, est une réponse simple à la question simple “pourquoi charger plus de données que nous ne pouvons en afficher ?”.
Qt : pourquoi et quand ut... La gestion des threads dans Qt est simple mais elle mérite quelques explications car elle engendre souvent des problèmes conceptuels chez les développeurs peu expérimentés en Qt.
Qt : l’influence du... Lorsqu’on développe une application mutli-plateformes il est important de se poser la question des performances sur les plateformes ciblées. A machine égale, selon le compilateur utilisé les
Adopter les flux tirés d... Nous abordons un des points essentiels de l’architecture réseau et applicative efficace et économe : les flux tirés. Partagez cet article ! Abonnez-vous à notre newsletter !
Livre Maîtrisez Qt 5 ... La seconde édition du livre de Tristan Israël, Maîtrisez Qt 5 – Développement d’applications professionnelles, est parue. Vous pouvez le découvrir sur le site des éditions ENI.
Qt : distribuer ses appli... La distribution d’une application est une étape importante de la vie d’une application, elle nécessite d’être pensée très tôt dans la conception. Cette série d’articles présente les
Qt : comment implanter un... Il existe plusieurs façons d’implanter des threads dans son application Qt.  Voici la méthode que je préconise. Partagez cet article ! Abonnez-vous à notre newsletter ! Si
Qt : Traiter une liste de... Pour qu’une interface graphique reste fluide aux yeux de l’utilisateur, le thread qui la gère ne doit jamais être interrompu plus d’une poignée de millisecondes. Or le

Laisser une réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *