Reprise du message précédent :
c'est pire, on l'a déja dit faut s'attendre à moins d'optimisations si on parcourir un tableau avec un pointeur
 
et accessoirement faudrais controller les allocations dynamiques

et j'ai horreur des "+ *machin++"

 
 
si on déclare un tableau facon

 
est ce que l'on nottera une différence de vitesse dans la suite du code par rapport à une déclaration de type

 
 
juste pour savoir, car il doit y avoir une différence au niveau de la répartition des données en mémoire non? => plusieurs vecteurs éparpillés contre un gros bloc avec la première méthode? ca j'avoue que j'ai oublié

on peut passer des données en double vers des long long facilement?
on y gagnerai un facteur de vitesse de 2?

c'est mal. (le tableau de pointeur là)

déjà t'es vraiment sûr d'avoir besoin de double ?
y'a un exemple de ton truc qui marche là ? (le binaire, une image source et  traité que je comprennes ce que ton bignou fait)

 
 
ben ouai si tu suis le raisonennement c'est encore moins cache-friendly puisque ta matrice est fragmentée par lignes et que les données sont toujours chargées en cache par bloc contigues

 
oki doki, oui, c'est en effet logique, mais au final,mieux vau une matrice 2D ou un vecteur ligne qui contient la matrice dépliée?
 
car metton que l'on traite comme ici présenté ligne par ligne mais aussi colonne par colonne, faudrai que l'on fasse des sauts de grande taille dans le vecteur pour rejoindre 2 éléments de lignes voisines plutôt que un saut unitaire pour passer au voisin de colonne...

un vecteur ligne qui contient la matrice déplié

 
je viens de faire les tests en FLOAT, ca reste correcte, donc, oui, on peut passer en float !!!
 
ce que fait l'algo là?
si tu n'as pu le compiler, imagine : il balaye chaque ligne de la gauche vers la droite avec un effet filtre passe bas. donc, en gros, sur une image, ca smoothe les arrêtes d'orientation verticales et la réponse est assymétrique entre la gauche et la droite
c'est juste un algo pour tester en fait. mais c'est une bonne base pour apprende à optimiser car il y a plein de données à traiter

 
=>
 

 
?

 
y'a rien à compiler, ton code tel quel il ne peut générér que des blobs artistiques.....
 
edit: en fait non c'est pas compilable si Taz passe et vois ton #include <iostream.h> et le cout atteinable comme ça il va te chier une pendule

 
pardon autant pour moi:
 

 
si tu mets le value=0 avant la 3ième boucle, ca veut dire que le premier pixel de la ligne commence avec value=0 pour lui seul, par contre, les pixels suivants connaitrons grâce à 'value' le résultat du pixel précédent d'ou un effet filtre passe bas (smooth, blur suivant le vocabulaire)
 
ca fait un genre de filtre pixel(i+1)= alpha*pixel(i)+(1-alpha)*nouvelleValeur
 
si tu met le value=0 à chaque tour de boucle...ben ca sert à rien

oui j'ai reposté derrière.

et mets tes tau/valeur en float.  
 
en fait ça changera rien suivant la config du fpu (en 80x86 sans sse bien sûr).

 
 
oui, j'ai tout repassé en float, en effet pas de changement de vitesse (je suis sur un p4)
mais il y a moyen de jouer avec les sse avec les float non, genre gérer 4 floats à la fois par opération? avec les intrinsics

oui...
 
mais tu as déplacé le for( NBloops ) ?
 
parceque ça risque de faire une sacrée différence. (enfin j'espère )

 
 
le for( NBloops ) ne sert qu'à exécuter plusieurs fois la boucle pour avoir une valeur moyenne du temps d'éxécution, autrement cette boucle n'a pas lieu d'être

a bon lol je suis déçu.
 
et bien si tu le fais, tu risques quand même de voir une différence

Maintenant plus rien. J'ai encapsulé tout mes codes de manip matrcioielle ALtiVec dans une bibliotheque (cf ma signature)

 
Moi je trouve un gain de x10 en mettant "NBloops=10" pour le faire correspondre au commentaire        

 
héhé, bien vu, je viens de corriger la bétise

là, je viens de transformer la matrice en un seul vecteur et le tout en float, j'ai un gain de 1.5...

les lignes sont les mêmes dans ton windowfilter ?

dans window fillter peut se trouver n'importe quoi, une constante=>remplacer le tableau par une simple constante, oiu alors une valeur différente pour chaque pixel, ca permet de changer l'effet du filtre localement

tu peux montrer ton code actuel ?

avec quoi tu compiles ? avec g++ ca ne compile pas (variables non déclarées + 4 pages de warnings)
 
index, result et IDstop ne sont pas déclarées, IDColumn et value ne sont pas utilisée ??

oups, g raté des copier coller, je remodifie

 
c'est fait

pour moi c'est 2x plus rapide avec ta premiere version (g++ -O3 ..., version 3.2.2)
 
#include <iostream.h> -> #include <iostream>
 
et ajoutes 'using namespace std;' au debut du main
 
unsigned int NBcolumns=640;
unsigned int NBrows=480;
->
// ne prefixes jamais par un _, et déclares les dans le main tant qu'a faire (toujours en portée minimale)
const size_t NBcolumns=640;
const size_t NBrows=480;
 
le type de retour de std::clock est std::clock_t
 
et surtout déclares tes variables en portée minimale et seulement dés que tu en as besoin, et utilise 'const' quand tu ne la modifies pas

 
 
2*plus rapide avec la première version? c'est bizarre chez moi, c'ets limite l'inverse... avec g++ O3 sur un pentium 4 prescott
 
on m'a dit que avec les boucles while c'était plus rapide, est ce vrai?
 
en tout cas, quelle est la méthode la plus appropriée : tableau 2D ou vecteur 1D?

 
ca sent la fumisterie. au pire desassemble, mais franchement ca sent la vieille legende facon "ok, c'est tout crado mais c'est rapide"

 
pour c'est logique que le premiere soit plus rapide, apres si c'est l'inverse chez toi je peux pas dire
 
 

 
dans ce cas je dirais tableau 2D puisque ton calcul dépend de 2 dimensions
 

 
for et while sont deux mots cles pour construire une boucle, sémantiquement un for à toujours sont équivalent en while (et inversement) il n'y a donc aucune raisons (je penses) que le code généré soit différent

 
 
le fait que ca ralentisse viens je pense du fait que les données de la dernière boucle ne sont pas contigues, (on fait des sauts de _NBrows), y a t il moyen de faire du prefectch pour mettre en cache les futures données avant le prochain tour de boucle?

dans la premiere version il n'y a pas ce probleme
 
essayes aussi avec une bibliothèque de templates pour gérer les matrices et autre (boost::ublas, blitz++ ou celle de joelF)

 
c'est vrai que je suis assez d'accrd avec toi lol

 
Si le filtrage peut-etre décrit comme un produit matriciel ... Avec la réutilisation de "value", je ne sais pas ce que ça donne ...
 

en effet c'est le gros probleme ca, le calcul de outputFrame[n] dépend de outputFrame[n-1], ceci dit je ne connais pas trop ces bibliotèque et je sais pas si elles permettent de construire ce genre  d'expressions
on peut aussi voir l'algo d'une autre facon (quitte à réorganiser les données ligne->colonne en colonne->ligne) en bouclant sur les colonne ca se résoud en une unique expression vectorielle
 

oui, on peut écrire cela sous la forme que tu propose bien entendu, mais qu'est ce que ca change si on ajoute la variable temporaire value?
 
est ce que value permet de garder cette donnée temporaire plus proche du processeur ou est ce que l'expresiion  

suffit?