Fast pixel routine - Page 2

Erf mais on peut encore optimise!!!

on peut tjrs optimiser

Heu...
Je veux pas te vasser Timad, mais ta dernière routine est en théorie exactement aussi véloce que celle de Pollux. Ta table de cycles est erronée
Et ton bench aussi

La table de cycle de timing est approximative.. fait le bench on calc et tu verras...

Hum hum...
Je demande confirmation d'un, disons, plus "avancé" que toi, parceque c'est louche quand même, pourquoi Motorola mentirait ?

Au fait, j'ai oublié de dire que j'explose vos deux routines. Attendez 2 mn que je passe du papier au clavier

erf j'ai jamais dit que c'etait la routine la plus rapide....
il suffit d'aborde le probleme d'un autre angle de vu avec plus de precalcule, et on peut largement atteindre les 32000 c/S...

"Au fait, j'ai oublié de dire que j'explose vos deux routines. Attendez 2 mn que je passe du papier au clavier "

zZz² ... je m'endore
[edit]Edité par TiMad le 31-10-2001 à 18:27:06[/edit]

Nan désolé j'ai eu un peu trop confiance en moi, j'y arrive pas.
Bravo donc à Pollux (ou toi si vraiment y'a des erreurs dans les tables)

erf on s'en fou qui a reussit... l'important c'est d'avoir trouve la routine la plus rapide...

mais non justement!!! je viens de regarder, move.l a0,-(a7) = 14 cycles, pea (a0) = 12 cycles

Donc bravo TiMad (mais avec une vraie convention d'appel c PpHd qui gagne )

Bon je crois qu'il aura eut une reponse a sa question Cyberplague
[edit]Edité par TiMad le 31-10-2001 à 23:49:38[/edit]

Ben merde ma table dit que c'est pareil !

put1! moi non... en fait, je dois en avoir 3 ou 4 mais ttes ac des valeurs qui diffèrent sur certaines instruction... y a pas qqun qui aurait une table FIABLE ?

t'en a pas une officielle la dedans ?

Dites les gars, vous avez oublie dans l'ancien topic ma super mega routine de la mort qui tue, qui mouline a plus de 60000 pixels / seconde.
La c'est totalement different, et ca mouline grave
Comme dirais TiMad : precalcule !

Et au passage je crois que votre derniere routine avec le double not fouare pour des valeurs > 3 de d0 (100 par exemple).

pphd: 60k... elle est ou ta routine?

Je pense avoir exagere. Mais plus serieusement, je pense qu'elle fait plus que 40k.
C'etait la routine qui a mis les autres KO.
allez cherche. Je suis sur que tu vas trouver. t'es encore plus bourrin que moi.

Erf pour la lib que je suis en train de programmer, j'ai fait un petit arrangement.. en effet, j'utilise des plans de taille: 64*160 (en octets) ce qui pemet d'optimser le probleme au niveau des sprite (en effet on peut afficher a des coordonnées jusqu'à (-32,-32) a (240,190) mais aussi au niveau du calcul sur le positionnement de la ligne.. il suffit de faire un lsl.w #6,dx ce qui prend un peut plus que 6 cycles...
inconvegnent;-(: je perd 8 cycles a chaque fois: addq #32,d0 addq #32,d1 ; pour toutes les routines

Sinon au niveaux des timing...il ne sont pas tout a fait exactes, car j'ai fait la routine de timing en C.. donc dans le timing, il est compté aussi la boucle while(i) { fnc(args..); k++; }... les routines sont donc legerement plus rapides.. surtout qu'il me semble (j'ai pas encore verifier.. que lorsque l'on appelle un asm("") dans tigcc.. il sauvgarde tous les registres.. il est donc fort possibles que la derniere routine de ce poste atteigne les 40k (max)...

Mais bon pour le moment j'ai pas le temps de cherché.. (salte de prepa de merde() je verais ca samedi ..

De plus dans l'appele de la routine...
il faut compter les: move.w #x,d2 et move.w #y,d1 non optimisablen en moveq (bein oui c'est pas du jeu) a chaque appele de la routine pour le timing..

Au fait le movea prend combien de cycle dans ta routines, car j'ai pas cette instruction dans mon fichier de timing ;(

[edit]Edité par TiMad le 06-11-2001 à 12:18:05[/edit]

subq #32 n'existe pas.

PpHd, tu compte réleler le code de ta super routine un jour ? (car dans les ours qui viennent, ça peut m'etre profitable

pas rien que pour toi, RV

PpHd> ptet que Timad voulait dire qu'il perdait des cycles en ne pouvant pas faie subq #32...

je m'en doute bien, mais qui ne tente rien n'a rien

Non, elle est inutilisable : elle prend toute la RAM disponible

heu.. de toute maniere je me suis plante..c'est addq #32,d1... (ce qui est beaucoup plus logique...)
mais bon le probleme de ta routine precalcule est qu'elle est enorme (bein oui quand meme) et que elle ne peut pas s'applique pour plusieurs plans... (je parle de celle de ce topic)

quand a l'autre elle est un peu bourin quand meme

addq #32 n'existe pas non plus.

Whouaa TImad tu m'étonnes :
- addq et subq n'admettent en opérande source que des valeurs entre 1 et 8
- lsl.w #6,dn bouffe BIEN PLUS que 6 cycles : 6 + 2*6 = 18 cycles


[edit]Edité par Thibaut le 07-11-2001 à 19:09:06[/edit]

non, c en fonction du décalage !
quelle merde ce 68000 !