PowerPC et DCBZ (pour Krabob)

[anonyme]

anonyme

#25726

Pour ce qui est de la trick du DCBZ ça marche sur tous les G2, G3, et G4, mais pas sur G5. le G5 à des cacheblock 2 fois plus grands que les autres PowerPC, verdict cette méthode créé un buffer complètement foireux.

A ce propos Apple conseille donc depuis un sacré moment de ne surtout pas utiliser cette trick.

Dixit le puissant Kakace.

[anonyme]

anonyme

#25727

Salut !

Petit précision, la taile des lignes de cache pour le Power PC

970/970FX est de 128 octets et non 64.

De plus, le FX (et peut-etre le pas FX) peux etre configuré pour que

dcbz n’affecte que 32 octets.

Cette instruction ne devrait être utilisé que par l’OS car lui seule

doit savoir sur quelle PowerPC il tourne.

Cordialement.

[stan]

stan

#25728

Qu’est-ce qui empêche un programme de connaitre le processeur sur lequel il tourne et d’agir en conséquence ?

[krabob]

krabob

#25729

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 des 32 octets concerné[edit]<-j'avais dis une connerie je l'ai corrigé.[/edit] avec chargement implicite des 128: d’ou ralentissemnt au lieu d’accelerations [edit: ralent. par rapport à un dcbz en G4](mais pas bugg.) [edit] et en fait ce serait le meme ralentissement qu’une écriture normale. Dés lors utiliser dcbz ne peut pas être dangereux ! [/edit]

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’une 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.)[edit]si un dcbz ralenti un G5 autant que n’importe quelle écriture, il n’y a plus de raison de faire du cas par cas.[/edit]

Pour le reste, exec est sencé informer sur le processeur présent.

[edit] Apple ne conseille pas d’utiliser dcbz, mais dans l’univers PPC il n’est pas conseillé de faire de l’assembleur au même titre ! [/edit]

[anonyme]

anonyme

#25730

@stan:

Je me suis mal exprimer:

Bien sur, le programmeur peux toujours essayer d’éxcuter du code

optimizé pour le PowerPC sur lequel il troune. C’est en particuler

vrai avec l’Altivec.

Mais, pour cette instruction « dcbz » (et co), je pense qu’il serai

préférable de la garder pour le système.

-> En particulier qu’on regarde la doc et les erratas

Bye

[anonyme]

anonyme

#25731

Krabob, utiliser DCBZ est extremement dangereux !!!!!!!!!!

si tu prévois ton code pour un G4, tu DCBZ 8 words à zero, tu les remplis avec ce que tu veux, et tu les stores, ça marche

tu lance le code sur un G5, tu DCBZ 32 words à zero, tu en remplis 8, et tu stores……… Tu viens de niquer 24 words.

Félicitations, tu vas bientot planter

[krabob]

krabob

#25732

Krabob, utiliser DCBZ est extremement dangereux !!!!!!!!!!

Faux:

http://developer.apple.com/technotes/tn/tn2087.html

Ou tu pourras lire:(je met en gras les trucs interessant.)

Developers have assumed that DCBZ operates on 32 byte chunks of data because the cache lines in previous Macintosh PowerPC systems have always been 32 bytes in size. However, the cache line size in the G5 is 128 bytes. The DCBZ instruction on the G5 still operates on 32 byte quantities. However, it does so in a very inefficient manner — when a DCBZ is encountered, the entire 128 byte cache line containing the requested 32 bytes to be zeroed is fetched from memory. This typically causes a cast out of a cache line, which, if dirty, must be written out to memory. Once the 128 byte cache line is loaded, the desired 32 bytes are then zeroed. Thus, DCBZ in the G5 has three detrimental effects on the performance of existing programs: Loops written using existing DCBZ instructions that stride by 32 bytes will cause redundant, unnecessary DCBZs to be issued; up to 75% of the DCBZs will already have their requested data in cache, already fetched on behalf of an earlier DCBZ. However, the subsequent DCBZs are still necessary to zero out the 32 byte chunk of the cache line. If the stride between DCBZs is greater than 128 bytes, then a great deal of memory bandwidth is wasted because the CPU can only make cache line-sized requests to memory, and as little as 25% of the memory bandwidth is useful. The intent of most code that uses DCBZ is to avoid a store miss to memory. In most cases, the G5 implementation will actually cause a store miss. The use of DCBZ should thus be assessed with great care. If possible use the DCBZL instruction instead of DCBZ.[… lire la suite sur le lien en haut, c interessant aussi, DCBZL, lui est vraiment dangereux..]

ce que tu lis ici implique que le comportement d’un dcbz sous G5 est le meme que sous G4, ça ne peut pas générer de bug, juste ralentir un chouïa.(d’aprés mon expérience du PPC, ça dois ralentir infinitésimalement sous G5, pasque les 3 dcbz inutiles n’entrainent pas de load ou de store re-edit: (dans le cas d’une écriture linéaire.))

Mais je sais d’ou viens l’erreur de kakace: c’est les ingénieurs mac qui ont mis à jour qu’il fallait un DCBZL, les premiers G5 n’avait qu’un DCBZ actif vers 128 octet. IBM a du revoir sa copie, d’ou DCBZL et ça a rélenti l’arrivée de G5 y parait cette histoire.

Youpi ! j’ai encore raison !

DCBZ IS SAFE AS MILK !

[anonyme]

anonyme

#25733

DCBZ IS SAFE AS MILK !

Ouais, il faut juste pas l’utiliser sur n’importe quelle CPU, a par ca ..

De plus, le comportement de dcbz sur G5 est configurable, c’est a dire que cette instruction peux aussi bien affecté 32 octects que 128, sans que le programmeur ne puisse rien y faire (sinon testé l’effet et adatper son code en conséquence).

@Krabob: On peux utilisé « dcbzl » sur un PowerPC « classique » ? cet opcode n’est pas dans la doc.

Bye

[krabob]

krabob

#25734

Ouais, il faut juste pas l’utiliser sur n’importe quelle CPU, a par ca ..

FAUX !relis au dessus ! dcbz à le meme comportement quelque soit le powerPC, meme sur G5 !!!

De plus, le comportement de dcbz sur G5 est configurable

FAUX !relis, c’est le comportement de DCBZL qui seul varie selon le cacheline. dcbz efface 32 octets quelque soit le cas de figure !!! DCBZL date du G5, a la demande express de mac. Mais c’est pourtant clair j’ai meme mis en gras, donné le lien et tout !!! Sa nouveauté explique qu’il ne soit pas dans les catalogues d’instructions, de toute façon une ABI décide de la présence ou non d’une instruction.

[anonyme]

anonyme

#25735

FAUX !relis au dessus ! dcbz à le meme comportement quelque soit le powerPC, meme sur G5 !!!

Si je me fis a la doc d’IBM le comportement de dcbz est configurable (32 ou 128 octets). Le comportement sous Mac OS X est surement d’effacer 32 octets, mais peut-etre que c’est différent sur d’autres OS.

On peux même configurer le CPU pour que « dcbz » genere une expection « illegal instruction »

Bye

[krabob]

krabob

#25736

Si je me fis a la doc d’IBM

Ta précision est interessante.

Dans ce cas précis, Mac a des format d’executables PPC depuis 1994, et depuis ce temps, utiliser DCBZ peut accélérer jusqu’a 4 fois une écriture, donc il est évident qu’énormément d’applis se sont mise à l’utiliser A JUSTE TITRE jusqu’aux G5. je sais que dcbz a fait l’objet d’aller retour lors de l’intégration du G5 chez mac, apple forçant IBM a créer une nouvelle instruction et laisser a DCBZ un comportement constant.

et nous constatons que le doc IBM auquel tu te référes n’est pas completement raccord avec la page mac. Mais si effectivement un systéme peut gérer une instruction (ici DCBZ) d’une maniére ou d’une autre (management JIT, exception,microcode.), il est plus rare de voir apparaitre une toute nouvelle instruction dans un assembleur: DCBZL. Ton doc ne fait pas référence à une instruction qui existe. Ca montre simplement qu’il est antérieur aux implémentations finale du G5 (les BDD de doc IBM accessible sous le net sont de vrai bordels). Aucun systéme actuel n’irait implémenter DCBZ pour 128 octet sous G5, vu que DCBZL est une réalité. Je ne modifierais pas mon article sous gurumed, et conseillerais l’utilisation de DCBZ a quiconque sera désireux de tirer réellement partie de ses BUS.

Et n’oubliez pas quand vous trouvez des descriptions de mnemoniques de vérifier si elles s’appliquent a la famille « PowerPC » ou a la famille « P.O.W.E.R. » Ca aide aussi.

[anonyme]

anonyme

#25737

@krabob:

Les recommandations d’Apple ne s’appliquent surement qu’au Mac OS X qui doit configurer les CPUs de maniere a que son comportement soit conforme a la doc d’Apple.

La doc d’IBM sur lle 970 est pour n’importe quel architecture/OS.

Donc, il sont surement tous les deux vrais

Ceci dis, si un codeur utilise « dcbz » ou « dcbzl », il ne peux pas être

sur que son programme marchera sur certaines machines/version de

l’OS…

Bye

[krabob]

krabob

#25738

> Donc, il sont surement tous les deux vrais

Mega-d’accord.

>Ceci dis, si un codeur utilise « dcbz » ou « dcbzl », il ne peux

> pas être sur que son programme marchera sur certaines

> machines…

remarque Interessante à faire la aussi:

Premier point:

Dans le cas d’un source a recompiler qu’on imaginerais être

compatible multi-systémes, mais ces systémes étant PPC,

on pourrait imaginer faire de l’asm PPC inline:

Dans ce cas, les lignes ASM, memes sans dcbz doivent

tenir compte de l’ABI, et de l’ABI seule. L’ABI spécifie le role des registres, mais aussi si ton contexte est 32 ou 64bit, ET le role exact de dcbz/dcbzl. donc dans du C tu pourrais avoir:

#ifdef ABI_mos32bit

tel code ASM

#endif

#ifdef ABI_OS4_32bit

tel code ASM

#endif

#ifdef ABI_mos64bit

tel code ASM

#endif

#ifdef ABI_OS4_64bit

tel code ASM

#endif

Quand je conseille d’utiliser DCBZ pour accelerer son code, c’est dans le cadre d’une ABI donnée, pour un exécutable donné. l’ABI décidant impérialement du comportement du code. Une ABI ne peut pas être à la fois 32 bit et 64 bit.

Maintenant si tu lances un assembleur genre pasm qui compile pour UNE ABI tu vas te rendre compte que tu peux, avec ton ABI 32b préféré, UTILISER DCBZ pour accelerer tes codes. Ce ‘tu peux’ est lourd de sens, puisqu’il ->IMPLIQUE<- que le comportement sera le meme quelque soit le proc. C'est ton systéme qui en est le garant. Sur un G5, tu peux faire tourner des ABI 32b ou 64b, mais les ABI 32b doivent se comporter comme telle. De ce point de vue, il est évident que le doc IBM n'indique pas un comportement fixe pour dcbz (doc général non lié a une ABI) au contraire de Apple.(qui spécifie un comportement fixe pour chaque instruction dans chaque contexte.) edit: En d’autre terme en PowerPC on ne créée pas des executables pour une machine ou une famille de proc, mais pour une ABI . Mon cours ASM est trés clair là dessus.

Vous m’attaquez parce que je suis demomaker, ce qui n’a rien a voir ? Vous trouvez que les demomakers ont la réputation de hacker n’importe comment, alors qu’en 1990 ils n’avaient pas d’autres moyen d’acceder a un certains niveau (aucun docs), ce qui ne les a pas empécher de tirer le meilleur de leurs machines ridiculisant l’industrie du jeu ? Ouvrez les yeux: actuellement les groupes de demomakers font de l’objet, réalisent des outils qui innovent et qui pétent (demoPaja, weirkzeurg, karate) et si tu vas sur #amycoders tu verras que les vieux de la vielle s’occupent des demos de benchmarks pour ATI et NVidia. Pour moi en informatique, ya les demomakers et les feignasses.

Be aware of your datacache.

[anonyme]

anonyme

#25739

ah ces demo makers!

[soupir]

[Lanza]

Lanza

#25740

Une vraie démo n’utilise pas le système…