Optimisation d'une fonction img 2D - C - Programmation
Marsh Posté le 23-02-2006 à 12:07:13
il y a beaucoup de choses que tu peux pré calculées ('height/reduce', width*height, ...) quand meme, et utilises plus de constantes
aussi vérifie l'ordre dans le quel tu accedes aux éléments pour optimiser l'utilisation du cache, la tu parcours ton image en width->height et si c'est équivalent à un tableau [height][width] c'est pas bon
Marsh Posté le 23-02-2006 à 12:38:23
Code :
|
Marsh Posté le 23-02-2006 à 12:55:33
si reduce, width et height ne changent pas d'un rendu à l'autre, le variable cp et celles qui en dépendent peuvent etre précalculées dans une table au moment ou reduce, width et height sont fixés
Marsh Posté le 23-02-2006 à 13:03:39
Code :
|
Marsh Posté le 23-02-2006 à 13:27:17
euh tu redéclares tes variables à chaque tour de boucle, là...
Marsh Posté le 23-02-2006 à 13:34:58
à tester.
Sors les déclarations de la boucle, au pire ce sera pareil...et au mieux tu éviteras la création/destruction à chaque tour.
Marsh Posté le 23-02-2006 à 13:39:14
Code :
|
40 ms
Marsh Posté le 23-02-2006 à 13:42:28
Bon après tu peux p-e gagner en déroulant la boucle. Du genre remplacer ton i++ par un i+=4 et dérouler le contenu sur 4...
Marsh Posté le 23-02-2006 à 13:43:15
(si tu as un multiple de 4, évidemment. )
...et plus éventuellement (8, 16...?), faut voir ce que t'y gagnes et si tu peux.
Marsh Posté le 23-02-2006 à 13:43:53
ReplyMarsh Posté le 23-02-2006 à 13:46:28
(en faire plusieurs à la suite te permettrait de réutiliser tes indices aX au lieu de les recalculer pour chaque...)
Marsh Posté le 23-02-2006 à 14:01:30
red faction a écrit : si je maitrisait les template mais bon le projet est en C |
meme avec les templates du c++ tu ne pourrais pas dérouler une boucle dont le nombre d'itération n'est pas connu à la compilation, et un bon compilateur peu faire la meme chose
que représente width, height et reduce ? si c'est fixe entre chaque rendu tu peux tout précalculé
Marsh Posté le 23-02-2006 à 14:15:30
skeye a écrit : euh tu redéclares tes variables à chaque tour de boucle, là... |
ce qui ne change rien. plutot que d'optimiser à l'aveugle, regarde l'assembleur et fait des mesures. je suis pas sur du tout qu'il y ait une différence entre ton code du début et le dernier.
par contre ça :
#
a0=image+3*max(cpup-1,0);
#
a1=image+3*max(cpup,0);
#
a2=image+3*max(cpup+1,0);
t'as certainement moyen d'éviter de faire ces 3 max. idem pour les min.
Marsh Posté le 23-02-2006 à 14:17:27
skeye a écrit : euh tu redéclares tes variables à chaque tour de boucle, là... |
mais cesses donc de dire des anneries
Marsh Posté le 23-02-2006 à 14:19:25
taz a raison. Par exemple regarde ce que ton compilo fais de ca :
Code :
|
s'ils te sort bien les invariants de la boucle et remplace ta multiplication par un increment tout seul comme un grand, bin change rien, sinon fais le, la tu fais 3muls par pixel qui servent a rien
Marsh Posté le 23-02-2006 à 14:20:17
Code :
|
Marsh Posté le 23-02-2006 à 14:23:18
sinon tu fais des alias plein pot, d'une part ca peut perturber le compilo et d'autre part ca te fais faire un quintal d'addition inutile (tous tes a1...an)
Vu la facon dont tu accede à tes données, je crains qu'il n'y ai pas grand chose a faire en mmx
oups pardon c'est red faction le roi de l'alias
Code :
|
a part rendre la lecture penible, c'est quoi l'interet par rapport a a0[0] ?
Marsh Posté le 23-02-2006 à 14:29:01
chrisbk a écrit : sinon tu fais des alias plein pot, d'une part ca peut perturber le compilo et d'autre part ca te fais faire un quintal d'addition inutile (tous tes a1...an)
|
c quoi se bo*** je demande comment ameliorer on me dit : "tu peux pré calculées ('height/reduce', width*height, ...)"
Marsh Posté le 23-02-2006 à 14:29:06
Une petite suggestion à propos de:
memcpy(image,dest,len);
tu peux p-e t arranger pour faire les calculs inplace, avec un tableau plus petit (3 lignes de pxl) pour garder les valeurs initiales.
Marsh Posté le 23-02-2006 à 14:33:26
Pour éviter les min et max, tu peux envisager de travailler sur une taille d image plus grande d un pixel sur chaque bord.
Marsh Posté le 23-02-2006 à 14:34:13
chrisbk a écrit : |
chrisbk a écrit :
|
Bon ok cest pa bon
Marsh Posté le 23-02-2006 à 14:34:28
red faction a écrit : c quoi se bo*** je demande comment ameliorer on me dit : "tu peux pré calculées ('height/reduce', width*height, ...)" |
du calme chu tellement pas reveilé que j'avais vu que le topic etait de toi
Marsh Posté le 23-02-2006 à 14:34:59
nargy a écrit : Pour éviter les min et max, tu peux envisager de travailler sur une taille d image plus grande d un pixel sur chaque bord. |
oui mais il faut redecouper apres
Code :
|
210 ms pour du 1994x2610, qui dit mieux ??
joffre une glace a celui qui me donne une meilleure solution
Marsh Posté le 23-02-2006 à 14:35:14
bah tu vas pas me quoter 15x non plus ?
red faction a écrit : |
nan mais jpense ca change rien au code generer, c'est juste que c'est moche
Marsh Posté le 23-02-2006 à 14:38:22
bah moi non plus jsuis pa reveille
deja que jme suis amene a la bourre au taf
10h30 c pa des heures
Marsh Posté le 23-02-2006 à 14:53:53
Allez, courage: découpe ton algo en:
Et fait sauter les a1, a2, etc. dans la partie du centre....
Marsh Posté le 23-02-2006 à 15:39:10
Taz a écrit : ce qui ne change rien. |
C'est bien ce que je disais, au pire c'est pareil.
chrisbk a écrit : mais cesses donc de dire des anneries |
C'est pas pour aujourd'hui, ça.
...et essayer de dérouler un peu la boucle si possible pour gagner sur les calculs de positions, aneries aussi?
Marsh Posté le 23-02-2006 à 16:00:53
Citation : |
Peut ne s appliquer qu au tableau temporaire de 3 lignes.
Au total: Gain en mémoire + gain en cache + gain min/max
Marsh Posté le 24-02-2006 à 22:27:51
red faction a écrit : |
Bah, tu vas voir l'API de ta carte graphique...
Sinon la suggestion de Lam's et nargy est certainement la meilleure, ton temps de calcul devrait faire un bond.
Ou au minimum vérifie que min/max sont des macros et pas des appels de fonctions (en C, normalement c'est le cas).
Marsh Posté le 25-02-2006 à 08:52:19
personne m'écoute avec l'histoire des min/max à la con ...
Marsh Posté le 23-02-2006 à 11:49:58
A coup de grof j'ai remarque que cette partie de code prenait 50% du temps du rendu :S
Quel modifs je pourrais fait pour rendre cette partie un peu plus rapide ? (mmx?)
ici l'algo prend juste les 8 points voisin dun pixels et fait la moyenne, reduce est fixe a 3
eg : trilinearfilter(img,3,640,480)
Message édité par red faction le 23-02-2006 à 11:50:54