Comment ça?
Pour faire une copie il faut des load et des stores linéraires. DCBZ permet d’accélérer les stores linéaire, DCBT permet de précharger des loads bien à l’avance, mais dans le cas d’une lecture totalement linéaire ça n’apporte rien.
Que ce soit un DCTB par cacheblock ou un load par cacheblock, ça ramait du fion de la meme manière.
Par contre, je pense maintenant pouvoir faire de la copie qui a défaut de tourner très vite peut se caler à la vitesse maximale de la vitesse de lecture (soit 230 mo/sec sur G4, 200 sur G3). Mais pas mieu… Pourquoi ça lit si mal… je sais pas.
Actuellement, j’ai plus qu’une idée en tete, faire chier les Friedens pour ajouter un menu sous UBOOT pour modifier le cache mode, voir éventuellement faire un soft qui le permet moi meme.
je viens de vérifier chez apple que j’ai pas dis de bétise dans mon article, mais je le modifierais pour être clair:
effectivement le G5 a des CL de 128 oct, et dcbz dans ce cas agit comme une mise a zero avec chargement implicite des 128 octets: d’ou ralentissemnt au lieu d’accelerations (mais pas bugg.)
Mais pour les G5, il existe DCBZL une nouvelle instruction, qui vous l’aurez compris déclare les 128 octets à zero sans load implicite.
Et donc mon ami espagnol qui m’avait informé là dessus ne m’avait pas dis de bétise. Il m’avait meme dis que lors de l’intégration du G5 par apple, c’est apple qui avait mis à jour qu’il ‘fallait’ un DCBZL (le dcbz zeroait les 128 oct.) et ces premiers G5 ont du alors retourner en usine.(mais je ne peux pas le confirmer.)
Bon ça implique qu’un routine optimisé fasse du cas par cas, mais le gain est tellement visible que ça vaut le coup. (dans la startup de karate j’ai 6 ChunkyToplanar differentes.)
Pour le reste, exec est sencé informé sur le processeur présent.
Petite question d’ordre pratique : avoir la capacité de lire/ecrire si rapidement en RAM, en terme d’applications pratiques, qu’est ce que ça permettrais ?
On pourrait envisager d’optimiser des datatypes qui seraient capable de décoder et afficher des images énormes instantanément ?
Des players DivX capables de décoder des divx énormes (genre le trailer de Matrix) et l’afficher de manière totalement fluide ?
D’autres applications ?
Je suis juste curieux …
Si ces méthodes font leur preuves, il serait assez intéressant de les implémenter dans certaines fonctions systèmes servant à réaliser des copies en mémoire non ?
Voilà, mon article sur l’asm PPC ou il est question de tout ça et bien plus est en ligne sur gurumed.net version française:
dans la section: Outils et langages / Apprivoiser le PPC / Présentation de l’Assembleur du PowerPC.
http://www.guru-meditation.net/main.php3?root=510
et plus précisément :
http://www.guru-meditation.net/main.php3?root=510#dcbz
Note: l’altivec est lui aussi soumi à la cache, la problématique est la même. D’ailleurs( le bus) les accés mémoire seront d’autant plus sensible que l’altivec sera puissant: l’un est toujours à la bourre de l’autre (le plus lent).
Bravo Krabob, un article très intéressant et accessible, avec mes rudiments d’assembleur 68K.
PowerMac - G5 2.0 GHz - 1.7 Go RAM - Radeon 9600P 128 Mo - MorphOs 3.13 et Peg2 - G4 RIP
Mac mini - G4 1.42 GHz - 1 Go RAM - Radeon 9200 32 Mo - MorphOs 3.9
WinUAE sur HP Core2 Quad 8200
Epave de Mist FPGA remplacé par un Sidi
A1200 malade 😉 et A500 512+512Ko RAM Kickstart 1.3
Par hazard de chez hazard, je tombe sur un doc IBM des caches des G3: hé ben il existe des instructions de manipulation du cache de niveau 2 !!! la folliiiiie !
je l’ai lu en diagonale, mais ça peut interesser quelqu’un.
› Forums › AmigaOS, MorphOS et AROS › Développement › PowerPC et DCBZ (pour Krabob)
© 2024 Amiga Impact.
Construit avec par Thèmes Graphene.
