Toutes mes réponses sur les forums
-
Ca ne m’amuse pas vraiment de n’avoir que 30 registres (vu que r1 et r2 sont réservés à autre chose) lorsqu’il m’en faudrait au bas mot une soixantaine. Un registre de moins, c’est automatiquement un load et un store en plus (au minimum).
Et on ne peut pas faire autrement. Le code est constitué d’une boucle dépliée, laquelle enchaine 74 blocs composés de 6 instructions dont l’ordre est immuable (dépendances entre instructions, voulues par l’inventeur de l’algo). L’essai de décodage avec une clé RC5 suppose la manipulation de 29 données 32-bit, auquelles s’ajoutent des variables annexes (peu nombreuses, mais on est déjà à la limite).
Du fait des dépendances entre instructions, le code basique (tel que généré par GCC) n’utilise pratiquement qu’un seul pipeline, alors qu’il est possible d’exploiter 2 IU simultanément (sur 603e/604/750) pour doubler les perfs. Cette solution suppose qu’on teste 2 clés en parallèle pour faire sauter les dépendances et autoriser l’exécution dans 2 pipelines (software pipelining), ce qui double le nombre de registres nécessaires. Cette optimisation est déjà exploitée par le core G2/G3, mais pas forcément de façon optimale.
Dans ces conditions, un registre de moins est synonyme de performances dégradées. Et ça, j’aime pas
Ok, vous fâchez pas !
Le fait est que r2 n’est pas utilisé sous Mac OS X (pas de TOC), et est donc libre d’emploi (documenté comme tel). Je sais que d’autres ABI réservent ce registre pour pointer la TOC. Dans ce cas de figure, comme il s’agit d’une leaf procedure n’ayant aucun besoin de cette TOC, on peut imaginer pouvoir utiliser ce registre (à condition de sauvegarder son contenu).
D’un autre côté, ce même registre étant explicitement documenté comme étant réservé pour le système (par ces ABI), j’ai vite pensé qu’une interruption pouvait en avoir besoin, d’où un conflit d’interêt.
Quoiqu’il en soit, GCC n’est pas la réponse. Il s’agit de code ASM écrit à la main de façon à être le plus performant possible (GCC est totalement incapable de générer un code aussi efficace, et de loin). Je vais donc envisager une version n’utilisant pas r2, mais elle sera un poil moins performante
Pour info, j’essaye de voir si je ne peux pas optimiser un peu plus les cores RC5 (d’où l’inefficacité de GCC)
pour info la pile “recule” elle n’avance pas. ton exemple trashe la pile déjà alloué. tu as voulu dire:
char *a[PAGE_SIZE]; a[-1]=0;
Donc les gens qui ne se drogue pas et on une “réputation” informatique solide se trompent aussi tu vois.
Si je peux me permettre…
L’exemple d’Henes est le bon, même si initialiser le premier élément du tableau est de l’overkill puisque ça ne fait que dupliquer l’effet obtenu par la création d’une nouvelle trame sur la pile.
En revanche, écrire “a[-1]=0” est clairement un bug dont la finalité est d’écraser quelque chose, mais personne ne sait exactement quoi
Vous me permettrez d’avoir un avis différent
En dehors du fait que Crisot utilise l’instruction DCBZ (Data Cache Block Zero) pour optimiser les opérations d’écriture, le reste du code est tout ce qu’il y a de plus banal. Compte tenu du nombre d’octets transférés, qui est bien au delà de la capacité des caches, l’outil en question mesure effectivement la bande passante maximale permise entre le processeur et la mémoire. Autrement dit, sur chacune des configurations considérées, on ne peut pas aller plus vite ce qui signifie par la même occasion qu’on peut facilement aller moins vite.
Une petite parenthèse au sujet de DCBZ. Cette instruction permet de contourner un effet secondaire du mode Write Back qui veut que toutes les opérations de lecture/écriture passent par le cache. Sans cette instruction, le fait d’écrire une donnée provoque la lecture d’une ligne de cache depuis la mémoire, puis l’écriture de la donnée dans le cache (laquelle sera recopiée en mémoire plus tard). Lorsqu’on souhaite remplir une zone mémoire (et non pas copier des données), le gain est très significatif puisqu’on divise par deux la charge du bus mémoire.
La différence entre les opérations en 32 bits et 64 bits est marginale dans ce cas de figure (taille de la zone touchée très supérieure à la taille des caches). En pratique, le G4 recombine les données écrites dans un tampon intermédiaire (CSQ) de façon à procéder à l’écriture dans le cache en une seule opération (Store Gathering). S’il est vrai qu’il faut deux fois moins de stores pour écrire la même quantité de données, il ne faut pas perdre de vue qu’au final, le bus mémoire va induire un ralentissement certain puisque la bande passante est nettement inférieure à ce que peut soutenir la LSU. En lecture, c’est un peu différent : puisqu’il faut moins de loads, on élimine la moitié des latences introduites par l’accès aux caches ce qui conduit à un léger gain en performances.
Les G4 étant (à priori) les mêmes sur les plateformes considérées, les différences constatées ne peuvent venir que d’une configuration différente des processeurs (fonctionnalités désactivées) ou du hardware lui-même. A ce titre, ce genre de benchmark met en évidence ces différences en chiffrant la bande passante maximale. Une application quelconque ne pourra en aucun cas faire mieux, pourra souvent faire aussi bien (vu que le code n’a pas besoin d’être spécialement optimisé compte tenu du fait que le processeur est beaucoup plus rapide que la mémoire), ou parfois moins bien. Dans les deux derniers cas, il vaut mieux disposer de 260 Mo/s plutôt que de 180 Mo/s.
[edit] Pour info, un PowerMac G4 1.25 donne 750 Mo/s en écriture (à priori sans DCBZ) et 450 Mo/s en lecture pour un bloc de 16 Mo.
15 sujets de 1 à 15 (sur un total de 22)
- 1
- 2
