PowerPC et DCBZ (pour Krabob)
-
Suite à une conversation avec Krabob je me suis penché sur une instruction assembleur PowerPC du nom de DCBZ qui a pour gros interet de permettre l’écriture en mémoire systeme sans charger celle ci dans les lignes de cache.
Le résultat est impressionant:
de 125 mo/sec en écriture, je passe à 520 mo/sec.
Krabob, t’en pense quoi ?
j’en pense que ton bus se roule les pouces: Ton écriture est effective uniquement dans le cache.
La ou ça va te poser un gros probléme, c’est pour benchmarquer REELLEMENT les écritures maintenant: elles se réalisent n’importe quand aprés dans la ram !Pour les autres: je prépare un article sur l’asm PPC pour gurumed.net que je mettrais en ligne lundi, cette affaire y sera expliqué.
note : tu m’inquiétes tout à coup: ce que tu benchmarquais comme étant des écritures auparavant devait être en fait des lectures implicites 😮 (désolé)
DATA CACHE BLOCK to ZERO !
re-edit: y doit y avoir une instruction asm de validation totale
du cache. aprés ta boucle d’écriture, valide, puis mesure: le tour est joué. En plus avec dcbz tu as l’assurance que le bus n’est pas venu interférer en load. Bingo.
… sinon j’en pense que la prochaine demo universe va bourrer 2x plus.
j’en pense que ton bus se roule les pouces: Ton écriture est effective uniquement dans le cache. La
ou ça va te poser un gros probléme, c’est pour benchmarquer REELLEMENT les écritures maintenant:
elles se réalisent n’importe quand aprés dans la ram !
Ben en fait, chaque fois que les cacheslines sont validés et que le L1 est plein je pense.
Donc si tu t’amuses à écrire 16 Mo linéairement, à la fin des 16 Mo, seuls les 32 derniers ko ne sont pas encore validés.
Encore que y’a le L2 qui se fout en tampon, ça complique encore un peu la chose.
Comme je le disais mon test fait 16 mo 64 fois, le retour au début du buffer confirmant l’écriture de la fin du buffer. 16 mo fois 64, ça fait en tout 1 Go de donnée qui sont écrites. Je pense que les 32 ko non écrit voir les 512 ko non écrit du “L2” sont “négligeables”, en tout cas ça ne fausse pas GRANDEMENT le résultat.
Quand aux prochaines démos d’Universe, elles sont en rendu hardware, donc hormis quelques conneries j’ai hélas plus grand chose à optimiser, j’en suis malheureux
Hip !!
Quand aux prochaines démos d’Universe, elles sont en rendu hardware, donc hormis quelques conneries j’ai hélas plus grand chose à optimiser, j’en suis malheureux.
… la fin d’un mythe, snif…
!! qiH
/me qui n’est pas Krabob, mais qui a quand même lu ce thread, et qui le trouve très intéressant
Plus fort encore !!!!!!!!!!
J’écris maintenant à 728 mo/sec et non plus 520 !!!
avant j’avais:
write (*
pour 125 mo/sec
puis j’ai eu:
dcbz
write (*
pour 525 mo/sec. Mais auccune garantie que la fin du buffer soit vraiment écrit.
Pour m’assurer de l’écriture temps réel du buffer, j’ai fais:
dcbz
write (*
dcbst
Pour… 728 mo/sec!!! Et la garantie (?) que c’est écrit en fastram. Pourquoi plus rapide? non utilisation du L2 peut etre?
Je suis dépassé, je m’en réfère à maitre Kakace.
Effectivement, mon fake est bidon.
Dur dur lorsque l’on réfléchie de savoir mettre son cerveau dans le cache ou dans la ram à l’instant T.
pour DCBT, il n’a pas une quantité de cycle précise pour le mettre avant.
A mon avis, le CPU rappartri le block uniquement sur le temps IDLE du bus. De plus, ça dépend de ta bande passante mémoire.
Disons que sur nos machines, il faut un “temps raisonnablement long” avant
EDIT:
DSBZ rA, rB créé un block pour l’adresse rA+rB, SAUF si rA est r0… si rA est r0, il prendra rA=0, donc l’adresse concernée sera uniquement rB.
C’est exactement le meme phénomène que pour l’addition où add rC,rA,rB donne rC=rB lorsque rA=r0.
C’est juste les conditions d’utilisation habituelles de r0, rien de plus.
- Vous devez être connecté pour répondre à ce sujet.
