ASM: Peut-on utiliser r2 ?

13 sujets de 16 à 28 (sur un total de 28)

anonyme
9 février 2005 à 17h23 #32089
krabob: Ici on ne parle pas d’algo avec une utilisation mémoire intensive, etc. On parle d’un algorythme de cassage de clé RC5, dont le but est de tirer un nombre ultime de clé à la secondes, et dont un gain de vitesse de 0.002% suffirait à justifier la réécriture complète du code.

Personnellement mon rendeur de polygon pour « Zero » doit utiliser un truc comme 29 registres, et encore, avec nombreuses restrictions. Le nirvana étant pour ainsi dire de ne pas utiliser la mémoire et au moins possible les caches en évitant la création de spans buffers.
kakace
9 février 2005 à 17h50 #32090
@krabob

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
krabob
9 février 2005 à 18h09 #32091
kakace + crisot:

j’allais écrire un post de 30 lignes pour essayer de vous expliquer des trucs mais pfffff ah quoi bon ? d’ailleurs j’ai déjà assez parlé dans le vide.

pffffffff

Bon , laissez tombez.

allez y. fakez votre r2. Si ya que ça qui vous amuse. et mesurez vous la bite à 0.002 cm prés.

vous êtes pathétiques.
kakace
9 février 2005 à 19h25 #32092
@krabob

Si c’est pour le prendre sur ce ton, ça va être vite réglé : quand tu aura 25 ans de programmation en assembleur derrière toi, tu pourra peut-être essayer de m’expliquer quelque chose.

Ce que j’explique, mais que tu t’obstine à ne pas comprendre, c’est qu’avoir un registre de moins coute quelque chose. A titre d’exemple, il suffit de perdre 1 cycle sur un core G4 (AltiVec) tournant à 1.25 GHz pour perdre l’équivalent d’un 68040/40.

Par rapport aux performances brutes d’un G4, c’est négligeable (0,25%). Mais négliger ce gain revient à insulter ceux qui utilisent leur 68040 pour participer au même projet puisque leur contribution se voit rabaissée au rang de quantité négligeable, en plus de renier l’interêt initial qui est d’obtenir les performances maximales.

Quand on fait de l’assembleur, on le fait bien ou on ne le fait pas. Et le faire bien, ça veut dire jusqu’au bout (performance) et en respectant les régles élémentaires (si r2 est réservé, on n’y touche pas <== ça c'est pour Crisot).
anonyme
9 février 2005 à 23h16 #32093
kakace: Mais je n’y touchais pas à R2 quand il était réservé (WarpOs).

Je touche à R2 maintenant qu’il n’est plus réservé (Os4) et tu peux en prendre bonne note pour le client Os 4.

Quand on fait de l’assembleur, on le fait bien ou on ne le fait pas.
logo
10 février 2005 à 0h44 #32094
M’enfin… sont pas un peu susceptibles ces coders.

Allez, vous êtes tous beaux !

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
krabob
10 février 2005 à 9h59 #32095
les 680×0 et les PowerPC ont des fonctionnement suffisament différents pour bouleverser des régles d’optimisations.

Les optimisations qui était trés effective en 680×0 le sont moins ou plus du tout en PowerPC. Je suis géné par le grapillage de r2, car c’est un raisonnement vraiment ‘68000’, comme le dit crisot le gain va être de l’ordre du 0.002%, alors que se concentrer sur des optimisation de structurations mémoire te fera facile des gains de 10% ou 40%.

aligne tes structures, et rassemble les champs qui sont en méme temps en lecture sur des lignes de caches, et ceux en écriture sur d’autres( selon la passe), utilise dcbz, etc…

En powerPc (ou intel), parfois plus d’instruction assembler = plus de vitesse. sur mes textures mapping, j’avais 4 instructions en plus par accés texture pour scrambler la mémoire de celui-ci, plus une gestion de mip mapping et ça allait 40%plus vite comme ça (cache plus effectif) , pasque simplement ça fluidifiait les accés mémoire ! pourtant ya 4 ou 5 pages d’instructions en plus, et là les GPR ils tournent. Ben si si, 40%.

Sinon dans le meme genre d’idée, un pote coder avait réalisé une chunkyToPlanar en asm PowerPC, qui allait aussi vite avec des instructions de décalages, qu’avec des suites de « add » pour les remplacer. ( mais dans un contexte particulier d’écriture en chip.)

Sinon , quand on en est a grapiller comme ça en asm,

ça devient pathologique. Il y a forcement une meilleure maniére pour optimiser ton algo, mais pas celle là. En plus tu ne pourras jamais mesurer le micro-gain, et pour une bonne raison: il n’a aucun sens par rapport au fonctionnement réel.

Sinon j’ai écris 2 articles sur gurumed là dessus.

Je me permet de dire de vous que vous êtes pathétique, car tout ça, c’est pour casser des clefs machin: c’est du mesurage de bite entre male, et ça ne sert a rien d’autre qu’a faire perde du temps à des gens débousolé.
falcon1
10 février 2005 à 11h10 #32096
@krabob

tu serais pas un peu pinailleur???

si ce registre est réservé et qu’on fait un code portable, ben on ne l’utilise pas, c’est tout… et si ca fait un peu de mal aux perfs, ben soit on fait une version spéciale pour les cas où on peut utiliser r2, soit on se dit que c’est le prix à payer pour avoir un code portable, c’est tout…

enfin c’est mon avis…

par contre, je me pose une question, si c’est l’ABI System V qui dit que r2 est réservé, et sachant que AOS4 utilise cette ABI… euh, il y a pas un problème ??? (crisot disant que ce registre est inutilisé sous AOS4)

A moins que inutilisé et réservé soient synonymes, auquel cas, c’est mon français qui craint
krabob
10 février 2005 à 11h54 #32097
Ouai je suis d’accord, ça mérite pas d’envenimer le débat, et tout ceci reste trés interessant, d’autant plus si les avis divergent. (10 ?)

Par contre je note que mac utilise PowerOpen, comme warpos, et pas l’ABI System V comme Morphos,OS4 et PowerUp. Hors il avait été dit ou sous entendu dans plusieurs thread que mac utilisait SytemV. Mais le Mac connait plusieurs génération d’executable PPC donc on peut etre a -til les 2 ?

Qu’en est-il ?

Pour la difference sur l’utilisation de r2 antre Mos et OS4, l’abi S5 dit que le gestion de r2 est « laissé au systeme ». Donc on peut imaginer que OS4 permet de l’utiliser et pas mos, toujours sur la meme ABI.
kakace
10 février 2005 à 18h12 #32098
krabob a écrit :

les 680×0 et les PowerPC ont des fonctionnement suffisament différents pour bouleverser des régles d’optimisations.

C’est tout à fait exact.

Les optimisations qui était trés effective en 680×0 le sont moins ou plus du tout en PowerPC. Je suis géné par le grapillage de r2, car c’est un raisonnement vraiment ‘68000’, comme le dit crisot le gain va être de l’ordre du 0.002%, alors que se concentrer sur des optimisation de structurations mémoire te fera facile des gains de 10% ou 40%.

C’est généralement vrai aussi. Je dis généralement parce que dans le cas qui m’interresse, très particulier, le gain peut être notable.

aligne tes structures, et rassemble les champs qui sont en méme temps en lecture sur des lignes de caches, et ceux en écriture sur d’autres( selon la passe), utilise dcbz, etc…

C’est classique, mais cela ne concerne pas du tout l’algo dont il est question.

En powerPc (ou intel), parfois plus d’instruction assembler = plus de vitesse. sur mes textures mapping, j’avais 4 instructions en plus par accés texture pour scrambler la mémoire de celui-ci, plus une gestion de mip mapping et ça allait 40%plus vite comme ça (cache plus effectif) , pasque simplement ça fluidifiait les accés mémoire ! pourtant ya 4 ou 5 pages d’instructions en plus, et là les GPR ils tournent. Ben si si, 40%.

Cette méthode permet aussi d’améliorer le degré de parallélisme du code, et donc de profiter au mieux de l’architecture superscalaire. C’est d’ailleurs la raison du « software pipelining » massif utilisé pour implémenter l’algo dont il est question.

Sinon , quand on en est a grapiller comme ça en asm,

ça devient pathologique. Il y a forcement une meilleure maniére pour optimiser ton algo, mais pas celle là. En plus tu ne pourras jamais mesurer le micro-gain, et pour une bonne raison: il n’a aucun sens par rapport au fonctionnement réel.

Si on veut. Ceci dit, l’utilisation de l’asm n’a qu’un seul but : obtenir les performances maximales. C’est la seule justification valable (en dehors du cas très particulier d’un BIOS, par exemple). Si une fonction asm n’apporte qu’un gain négligeable, elle ne mérite pas d’être écrite en assembleur, parce que c’est une perte de temps inutile. En revanche, si le gain est conséquent, l’effort consenti mérite d’être poussé jusqu’à son terme pour justifier pleinement ce choix. Si on se contente d’une optimisation « moyenne », on peut se poser la question de savoir si l’absence de gain est tolérable et donc remettre en cause la nécessité d’utiliser l’asm.

Sinon j’ai écris 2 articles sur gurumed là dessus.

Je me permet de dire de vous que vous êtes pathétique, car tout ça, c’est pour casser des clefs machin: c’est du mesurage de bite entre male, et ça ne sert a rien d’autre qu’a faire perde du temps à des gens débousolé.

Faire un encodeur MPEG-A qui va plus vite que les autres, c’est aussi du mesurage de bite. Vu sous cet angle, toute optimisation tend vers le même but : avoir mieux que le voisin.

Ceci dit, je ne te permets pas de critiquer un projet sous le seul prétexte qu’il ne t’interresse pas. Et si casser des clés semble inutile, il n’en demeure pas moins que le classement de la Team Amiga lui fait un sacré coup de pub.

Mais tout ceci est hors sujet. La question initiale était pourtant claire, et je ne vois pas du tout pourquoi même les sujets les plus simples partent en vrille aussi rapidement. Ca c’est pathétique !
anonyme
10 février 2005 à 18h37 #32099
Krabob: Casser des clés c’est un concours qui est fait pour la beauté du geste et l’exploit technique.

Si tout ce qui est pour la beauté du geste et l’exploit technique ne sert à rien d’autre que mesurer sa bite, je vois pas pourquoi tu te fais chier à faire des démos et Karaté.
sg2
10 février 2005 à 18h38 #32100
Hi,

Pas la peine de tourner autour du pot pour des sujets dont la réponse peut être trouvée sur google.

– Sous MOS, pour des tâches natives, r2 contient la structure emulhandle, c’est le lien essentiel par lequel l’os tient la tâche. Si tu trashes r2, tu trashes MOS. Source : http://zapek.com/docs/morphos/morphos.html

– Sous OS4, r2 ne contient rien, donc tu peux l’utiliser, sauf pour des exécutables compilés en ‘baserel’ (soit small data basé sur un registre, en l’occurrence r2). Source : moi (en cherchant bien sur google on doit pouvoir trouver aussi)

Amigalement,

—

Stéphane
krabob
14 février 2005 à 17h51 #32101
sg2: Merci pour l’info au dessus.

@crisot:

Krabob: Casser des clés c’est un concours qui est fait pour la beauté du geste et l’exploit technique.

Attendez deux secondes… dans les classements de cassage de clef, le compte se fait par clef cassé par communauté, ou par moyenne de clefs cassé par machine, dans une communauté ?

Parce que si c’est par total de clef pour une communauté , c’est les plus nombreux qui gagne, et pas ceux qui ont optimisé r2. Je suis sur qu’il y a des nerds qui laissent tourner « 1+N » machines en permanence exprés. Alors, rc5, beauté du geste ? Non, mesurage de bite.