Voici un autre cas, différent. J'ai déjà entendu dire que les 68k étaient des CPUs lents. Croyance erronée.
C'est le code généré automatiquement (sans intervention humaine) par nos compilateurs C/C++ qui est lent. Nuance.
Voici un exemple édifiant dans miniGL. Là, le source en C/C++ :
Le compilateur utilisé est Gcc en mode -O3. Le résultat sera quasi le même quelque soit la version utilisée :
Cette fonction générée fait exactement 1196 octets.
En utilisant judicieusement les boucles (loops), il est possible d'obtenir le même résultat en seulement 94 octets !
Soit 1102 octets économisés ! Incroyable !! Cela représente tout ça :
Cosmos, grand défenseur des 68k, nan mais oh !
Quel est le résultat de la compilation avec les optimisations de GCC, notamment le -Os (optim. de taille) et le -Ofast (mais je sais pas si ces options sont accessibles sur Amiga)?
RépondreSupprimerAu pire avec les options -O3 ou -O2?
Je suis curieux de voir si GCC fait son boulot ou pas!
Ca dépends du code en fait... Bon là, c'est un cas particulier quand même, mais qui montre bien que les compilos font un boulot 'machinal', sans réfléchir : tu vois ce que je veux dire ?
SupprimerOui, je le sais ça, mais comme je sais pas ce que valent les optimisations de GCC pour l'Amiga... Je pose la question.
SupprimerMême si je suis conscient qu'un code mal écrit sera plus difficilement optimisable qu'un code bien structuré.
On paie toujours en instructions CPU ce que l'on gagne en portabilité et facilité d'écriture (le code interprété est plus coûteux que le code compilé, qui est plus coûteux que le code écrit en assembleur).
Tous les compilos sur Amiga se valent plus ou moins...
SupprimerDans le cas que tu présentes, il semble que la manière dont le code d'origine est écrit serait le point à remettre en cause. Et encore, il faudrait voir le code 68k généré complet mais sur le PPC, des registres sont utilisés pour les variables temporaires, pas la pile. Après, le code linéaire peut être critiqué du point de vue de la taille mais justement, une technique pour gagner en performance est le déroulage de boucle. Donc à voir ...
RépondreSupprimerIl serait intéressant de voir le gain obtenu par tes modifs.
Pour ce qui est des compilateurs, ils font la plupart du temps un excellent travail mais ils ne peuvent cependant pas corriger des problèmes de design, ou la méconnaissance des compilateurs, de comment les données sont accédées, etc.
Le gros intérêt des boucles, c'est déjà que le code est moins dense (là encore on gagne beaucoup d'octets), et surtout que cette nouvelle programmation utilise à fond le code cache en l'utilisant beaucoup moins, ce qui minimise considérablement le temps de transfert de la fastram au cache : 94 octets à mettre dans le L1 pour traitement est bien plus rapide que 1196 !!
SupprimerLe code 'déroulé', c'était pour le 68000 et le 68010, des CPUs sans code cache...
Supprimer