Optimisation vitesse - Page 1

ns d'ExtGraph, j'ai pensé, pour les fonctions masquées, à, plutôt que de faire : and.l [masque],(a0) or.l [sprite],(a0)En essayant d'améliorer la vitesse des fonctio
.l dn,(a0)

faire ça :  move.l (a0),dn
  and.l  [masque],dn
  or.l   [sprite],dn
  move

(masque et sprite sont dans des registres de données)
En supposant que ça irait peut-être plus vite, ce qui s'est confirmé lors des benchs. Le code est en effet légèrement plus rapide. À peine.
Puis, j'ai voulu compter les cycles quand même pour savoir combien de cycles je gagnais à faire cette méthode.
J'ai donc par ligne pour la première version : 20 + 20 = 40 cycles.
Et pour la deuxième version : 12 + 8 + 8 + 12 = 40 cycles.
Or, la deuxième version est plus rapide (très légèrement, 2-3

Savez vous m'expliquer pourquoi ?

a0 est un pointeur dans la mémoire. Le processeur doit effectuer des micro-instructions supplémentaire pour lire les données voulus dans la mémoire. Dans ton exemple 1 tu fait ça 2 fois.

Par contre dans l'exemple 2 tu met ça dans un registre et donc tu effecture l'opération 1 fois et ensuite pour lire le contenu de d0 ça ce fait en vitesse éclaire car le processeur n'a pas besoin d'effectuer des opérations supplémentaire.

Au final juste pour dire que de lire et écrire dans un regsitre et bien plus rapide que d'écrire directement en mémoire.


Kevin pourras mieux t'exliquer que moi, j'ai encore énormément de choses à apprendre dans ce domaine..

[EDIT]C'est d'ailleurs pourquoi on ma conseillé de mettre mes variables dans un registre, faire mes opérations et remettre le registre dans la variable

geogeo> je sais bien tout ce que tu m'as dit...
Je dis juste que par rapport à la doc je ne devrais avoir gagné aucun cycle donc pas de vitesse en plus.

C'est vrai que c'est bizarre:
1er exemple: 4 (an) et 0 dn
2eme exemple: 4 (an) et 4 dn

Peut-etre que le micro-processeur est plus long pour executer une instruction avec 2 (an) que 2 instructions avec chacune 1 (an).

geogeo> je sais bien tout ce que tu m'as dit...

Je me disais bien que je t'apprenderais rien.

Je dis juste que par rapport à la doc je ne devrais avoir gagné aucun cycle donc pas de vitesse en plus.

Dans la doc ils précisent qu'il y a un calcul à faire car les résultats provienne t d'un Atari ST...

Je ne vois pas mais c'est vraiment une question très interessante.

MOVE Instructions:
                                               d(an
.b.w/.l    dn   an     (an)  (an)+ -(an) d(an) ,dn)  abs.s abs.l

dn         4/4   4/4    8/12  8/12  8/14 12/16 14/18 12/16 16/20
an         4/4   4/4    8/12  8/12  8/14 12/16 14/18 12/16 16/20
(an)       8/12  8/12  12/20 12/20 12/20 16/24 18/26 16/24 20/28
(an)+      8/12  8/12  12/20 12/20 12/20 16/24 18/26 16/24 20/28
-(an)     10/14  10/14 14/22 14/22 14/22 18/26 20/28 18/26 22/30
d(an)     12/16  12/16 16/24 16/24 16/24 20/28 22/30 20/28 24/32
d(an,dn)  14/18  14/18 18/26 18/26 18/26 22/30 24/32 22/30 26/34
abs.s     12/16  12/16 16/24 16/24 16/24 20/28 22/30 20/28 24/32
abs.l     16/20  16/20 20/28 20/28 20/28 24/32 26/34 24/32 28/36
d(pc)     12/16  12/16 16/24 16/24 16/24 20/28 22/30 20/28 24/32
d(pc,dn)  14/18  14/18 18/26 18/26 18/26 22/30 24/32 22/30 26/34
Immediate  8/12   8/12 12/20 12/20 12/20 16/24 18/26 16/24 20/28l

Pourtant:
move.l (an),(an) 20 clocks
move.l (an),dn 12 clocks
move.l dn,(an) 12 clocks
move.l dn,dn 4 clocks

C'est peut-etre pas pareil pour les and ....

Bas pourtant dans la doc pour or et and ça fait 8 clocks.

geogeo
: Dans la doc ils précisent qu'il y a un calcul à faire car les résultats provienne t d'un Atari ST...

Je pense que nous n'avons pas la même doc.
J'ai la doc de motorola.

C'est plutôt mal parti pour moi.

C'est parce que les chiffres sont sur un Motorola 68000 standard et que les TI-89/92/92+/V200 utilisent la version à basse consommation. Il doit y avoir de légères différences.

La deuxiemme methode est de loin plus rapide

Pas de loin d'après mes benchs

ca aurait pas un rapport avec ce magnifique pipeline de prechargement des instructions qu'on avait essaye de decortiquer y a quelques temps?
enfin, je dis ca je dis rien hein...

oué c un truc du style sans doute.
lisez donc le chapitre du black book qui traite des *mangeurs de cycle* (c peut etre pas le nom exact !)
c TRES interessant

ah g retrouvé le nom exact :
4. Dans l'antre des mangeurs de cycles

http://www.calindex.com/livre-informatique-programmation-outils-developpement-agl-visual-initiation-programmation-graphique-assembleur.html

oui, je confirme, et heu le titre c'est pas "black book", mais "graphics programming black book"
et y a une version plus recente qui est blanche...
et aussi zen of graphics programming, dont quasiment tous les chapitres ont ete repris dans le black book, mais pas tous
et zen of code optimisation (y me semble qu'il y est integralement dans le bb cuila par contre)

>et y a une version plus recente qui est blanche...
c vrai ?
le nom est le meme ?
à la fnac y'a pas longtemps (cette année) g failli l'acheter en version noire...

j'ai pas fait gaffe au nom... en tt cas c'est le meme boukin, je l'avais vu a eyrolles a cote de l'ancien y me semble... a moins que ca soit a la fnac... chais plus

> La deuxième methode est de loin plus rapide
Les benchs ont l'air de montrer que ça n'est pas le cas - 2 à 3%, ça n'est pas très significatif.
Par contre, la deuxième méthode est plus grosse. Surtout si on ne peut pas faire sans détruire (et donc sauver/restaurer) un registre supplémentaire, et qu'on sauve/restaure moins de 3 registres (+8 octets au total - ça fait minimum +10%, la plupart des routines de sprite font moins de 80 octets)...

Sur les "petites" routines (8/16/32), ça n'est pas forcément la peine; ça l'est peut-être sur les X8.

les benchs que j'avais fait pour xlib m'avaient dit el contraire...
enfin Xlib est basé sur la 2eme methode il me semble.
pour vraiment bien bencher il faut dev la boucle ,sinon tu veras moins la diff (meme si c'est de maniere temp)

ha j'avais bencher pour les fonctions maskée (+ d'op) donc il se peut en effet que pour les fonction de gris clair ce soit l'inverse, je ferait des benc sous peu.

Tout ça pour dire que la doc est périmée, à mon avis beaucoup son dans ce cas.
C'est un peu normal car comme la dis Kevin le processeur des TI 'ai pas identique à 100% au anciens motorola car il doitminimiser la consommation d'énergie.

Reflechissez un peu. 2% de 40 cycles, ca fait: 0.8 cycles. A votre avis c'est possible cela?

Le truc qui doit changer (Mon opinion) est qu'une interruption (Logicielle / Hardware / Peut etre l'ecran) interrompt ou ralentit une instruction longue (and.l dn,(an) necessite 2 lecture de word, un calcul et 2 ecritures de word).
Bref ca fait parti des mysteres des Ti et ca avait ete longuement explique dans les archives du forum il y a 3 ans...

bref ce sont des mangeurs de cycles quoi

Ya le fait aussi que un cycle d'accée mémoire n'est pas forcement défini sa dépend de la vitesse de la mémoire, meme si le CPU prend x cycles

Pour ceux qui connaissent le 68000 au niveau electrique, je parle du /DTACK
Donc suivant comment les TI gere cela sa peut etre plus lent sachant que la premiere version fait plus de lecture en mémoire que la seconde

En tout cas, pour ExtGraph, je suis contre cette "optimisation": ça rajoute 4 octets et ça consomme un registre de plus, donc ce n'est pas une optimisation.

Tu es membre de la tict? Tu es impliqué dans ce projet?

Je suis impliqué parce que je suis membre de l'équipe de TIGCC et que c'est une future contribution à TIGCCLIB.

"En tout cas, pour ExtGraph, je suis contre cette "optimisation": ça rajoute 4 octets et ça consomme un registre de plus, donc ce n'est pas une optimisation."

bah moi je suis pour... c bete hein?