Quelques questions... - Page 2

dans le second cas, l'assembleur généré utilise probablement un dbra (decrement and branch) pour la boucle
cela implique que ton i est nécessairement stocké dans un registre, aussi => plus rapide pour le lire que s'il est en ram (ce qui est possible dans le premier cas)

La boucle utilise BitmapPut et tu dis que ca viens d'un accès mémoire en plus ?

sinon, vu la lenteur de BitMapPut, je ne sais pas si le fait que le compteur soit en RAM ou dans un registre joue beaucoup en comparaison.

Je crois aussi

Probablement parce que BitmapPut préfère que les clippings qui clippent la partie droite plutôt que la partie gauche ?

Plutôt oui. Et en plus à cause de l'alignement à 0 pour la coordonnée x sûrement.

au passage si tu veux gagner un tout petit peu, essaie à tout hasard de remplacer "i--" par "--i" dans ta boucle, je ne sais pas si gcc s'occupe de ça tout seul ou non

for (i=159; i--; )
si tu veux gagner encore

PpHd > tu devrais songer à t'expliquer un peu au lieu de te contenter de servir à rien, on peut même pas répondre là :]

Bah ... non ? J'ai pas sorti ça totalement au pif non plus hein, faudrait un peu plus qu'un "lol" pr être clair (surtout que son dernier ds ce forum à ma connaissance était parcequ'il n'avait pas la même définition de "variable globale" que celle du standard C, c'est un peu gros pr qqun qui ne peut pas s'empêcher de prendre tlm de haut à chaque post ^^)

Martial Demolins :
je sais pas combien de fois est plus rapide le code que j'ai écrit, mais rien que ça, ya pas photo quant au choix du langage quand on a absolument beosin de vitesse

Oui mais en C on peut aussi insérer du code assembleur. Ca permet de n'optimiser que ce qui en a vraiment besoin et de ne pas s'attarder sur le reste.

La programmation de jeux c'est quand même une catégorie spéciale et encore plus les moteurs graphiques.
La plupart du temps il n'y a pas vraiment de raison d'optimiser.
Mais bien sûr dans un jeu je suis d'accord pour optimiser les fonctions critiques : les fonctions graphiques, ...
Il y a le facteur temps qui rentre en compte aussi surtout pour moi qui suis pas bien à l'aise en l'assembleur.
sur ce j'ai une colle a passer moi "mais monsieur c'est Martial Demolins qui m'a retardé"

Martial Demolins :
d'ailleurs, c'est marrant qu'il ponde pas un truc du genre:

 move.w #158,d3
 movea.l 200.w,a2
 movea.l 1656(a2),a2
Loop:
 jbsr (a2)
 dbra.w d3,Loop
 rts

là, il fait un accès en RAM à chaque fois pour lire i, il fait un relogement en plus!!! (move.w i(pc),d0 ferait le même effet sans relogement), puis il recalcule à chaque fois l'adresse du ROM call... apparemment, GCC doit pas être parfaitement au point quant à l'utilisation des registres...

Non, GCC a parfaitement raison, il n'a aucun moyen de savoir que ClrScr() n'est pas susceptible de modifier i... Enfin si, il pourrait le savoir, mais en compilant l'ensemble du programme simultanément ^^ (ce qui est réaliste sur TI, mais pas sur PC, cible principale de GCC)

Et sinon pour i-- vs --i, c'est évidemment rigoureusement pareil qd tu ne te sers pas du résultat, par contre je pense que la suggestion originale était lié au fait qu'un compilo ne compilera souvent pas pareil une boucle while (i--) blabla; et une boucle while (--i) blabla; (pour GTC, c'est la première version la plus rapide, puisque c'est ce que fait dbf; je soupçonne que c'est pareil pour TIGCC, à moins qu'il soit assez intelligent pour changer la valeur de i)

Non mais là ton code est crade quand même . Il te fait quoi tigcc si tu mets le int i; à l'intérieur de la fonction ?
Ah au fait depuis quelques versions de tigcc il est possible de mettre des variables globales dans des registres (j'ai pas mal fait ça dans foblub), mais il faut le lui dire explicitement.

Martial>

En l'occurrence, non : si ce que tu veux c'est faire comme en ASM, à savoir dire "je sais que je suis le seul à toucher à cette valeur, mets la dans un registre", il suffit de copier la variable globale dans un registre, c'est pas plus compliqué/plus long qu'en ASM. Après c'est sûr que c'est pas forcément une optimisation à faire systématiquement (par exemple parce que ça peut être pratique de *ne pas* garder la valeur dans un registre et laisser le contenu dans la variable globale), et surtout les conditions dans lesquelles il faut le faire ne sont pas aussi claires que qd on programme en ASM, on est bien d'accord ^^


(et j'ai rajouté des trucs dans mon post précédent, tu n'as pas p-ê pas vu...)

Sally :
Ah au fait depuis quelques versions de tigcc il est possible de mettre des variables globales dans des registres (j'ai pas mal fait ça dans foblub), mais il faut le lui dire explicitement.

Mais ça n'est pas sans conséquences sur la qualité du code, évidemment, puisque ça monopolise un registre dans toutes les fonctions ^^ C'est uniquement pour les structures utilisées très souvent dans plein de fonctions différentes... (donc utile par exemple pour les interpréteurs, mais pas pour des masses d'autres programmes)

./47 > ben c'est sûr que tu pourras forcément toujours optimiser mieux à la main, par contre 1/ tu coderas moins vite, 2/ le résultat n'est pas portable. D'où l'intérêt de ne faire à la main que ce qui est critique ^^.
Ceci dit là tu comptes quasiment sur le compilateur pour deviner ce que fait ton programme, il est quand même pas censé faire ça. Logiquement si toi tu sais que ClrScr() ne modifie pas i, tu devrais utiliser dans la boucle une variable locale et mettre un j = i après la fin de la boucle. Je veux dire que tu peux optimiser ton code C : ce n'est pas parce que deux codes ont des résultats identiques qu'ils seront compilés de façon identique.

Pollux > oui c'est sûr, d'ailleurs mes variables doivent s'appeler en gros pc, sp et frame_pointer ^^

(surtout que son dernier ds ce forum à ma connaissance était parcequ'il n'avait pas la même définition de "variable globale" que celle du standard C,

A c'est vieux ca.

c'est un peu gros pr qqun qui ne peut pas s'empêcher de prendre tlm de haut à chaque post ^^)

Le standard, c'est le standard. La conception, c'est la conception.
Du point de vue d'une conception, c'etait une variable locale au module.
Mais globale au niveau du code C. C'est mieux ?
M'enfin depuis mon post, le niveau des reponses s'est élevé... #tagadapouetpouetlesauveurestpasse#

PpHd > tu devrais songer à t'expliquer un peu au lieu de te contenter de servir à rien, on peut même pas répondre là :]

Parce qu'il doit recopier les octets par decalage de la source pour aligner la destination, et qu'avec un depart a 0, on copie tout pour octet sauf le dernier qui a un masque, alors qu'autrement on decale tout, ce qui est plus lent. C'est mieux ? Mais ce n'est qu'une conjecture.

faudrait un peu plus qu'un "lol" pr être clair

Ton bitmapput doit prendre dans les 50000-100000 cycles (au pif). Au mieux, ta modif peut esperer gagner sur un compilo ultra-con une 20 de cycles.
Donc voila. Je ne vois pas ce que je peux ajouter. A moins que tu ne parlais de while (i--) et while (--i) ?

Vu la complexité de la modif, même pour peu de cycles, ça valait le coup de tenter : ça m'a déjà fait gagner 1 seconde sur 30 de calculs avec un compilo "ultra con" qui s'appellait GCC (je sais pas quelle version, c'est celui qu'on utilise à l'école). Alors ok l'asm géneré n'est pas le même, et je n'ai strictement aucune idée du pourquoi ça a fait gagner un peu (l'idée n'est pas de moi, c'était une suggestion des responsables du projet en question), mais on ne crache géneralement pas sur des trucs aussi simples à modifier.

hum vous parlez de la différence entre for (i = 159; i >= 0; i--) et for (i = 160; i > 0; i--) si j'ai bien compris ?
(ou les équivalents : for (i = 159; i--; ) et for (i = 160; --i; ) mais perso je préfère les premiers qui sont plus lisibles...)

Il y a effectivement une solution plus optimale que l'autre comme a dit Pollux mais là de toute façon il n'a pas le choix : il utilise la valeur de i à l'intérieur de la boucle... bon sinon dans certains cas on peut bien sûr utiliser i+1 à la place de i dans la boucle (genre remplacer i+5 par i+6 c'est sûr qu'on n'y perd rien), mais en l'occurrence pour naPO ça ne serait pas une bonne idée je pense ^^.

Sinon bob si tu parles juste de changer entre i-- et --i dans la troisième partie du for, ça ne change strictement rien puisque la valeur retournée par cette troisième partie n'est jamais utilisée et que la seule différence entre i-- et --i c'est la valeur que ça renvoie

vivi je parle bien de ça, et je ne sais pas ce que ça change mais j'ai déjà *vu* la différence donc ça va être difficile de me faire accepter que c'est strictement équivalent dans tous les cas coté assembleur géneré (du point de vue du C je connais la différence merci ); j'essaierai d'avoir l'explication par celui qui m'avait suggeré le truc à l'occasion

si tu parles du dernier paragraphe de sally, ça m'étonnerait qu'une version quelconque de GCC fasse la différence entre (void)i-- et (void)--i, ou alors c'était avant la naissance du 8086...

(sauf en C++, quand "--" agit sur des classes, à ce moment-là c'est pas forcément évident pour le compilo que les deux seront équivalents, et donc --i risque d'être plus efficace)

./54: Tout a fait d'accord. Je demande a en voir plus parce que c'est vraiment louche.

Bon, nouvelle question, qui fait que j'ai toute la mâchoire contre KK

Comment fait-on pour ne faire compiler que pour un modèle de calto ? (et pourquoi il a supprimé le wizard ce con )

ah oue quand meme

Pourquoi tu veux compiler que pour un seul type de calc ?

Parce que j'en ai besoin pour ce que je veux faire, au hasard ?