Reprise du message précédent :
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?

Pour du filtrage un peu sioux , un peu de pub :
http://forum.hardware.fr/hardwaref [...] 1774-1.htm

 
ublas c'est limite trop bas niveau. BLitz++ est pas mal, quadn a EVE mieux vaut attendre la 1.2 >.> qui gere SSE2

ublas bas niveau ? Tu parles bien de Boost.Numeric.Ublas ? ( et non des blas, lapack )

 
attention, ce que j'ai ecris faut voir ca comme du pseudo code mais qu'on pourrait ecrire avec une bibliothèque (genre celles citées dans le précédent message) qui fournit des vector et matrice avec opérations vectorielles (et utilisation des templates c++ pour déroulée les boucles et surtout construire des expressions templates)
 
l'interet d'utiliser ces bibliothèques c'est de construire des expressions sur des ensembles (scalaire, matrice, vecteur) en ayant la certitude que le code générée est optimun
 
tu as compris pourquoi la variable value (ou tout simplement le fait que le calcul d'un pixel sur une ligne est dépendant du précedent) ne permet pas de construire une expression vectorielle pour le traitement de chaque ligne et qu'on est obligé de traiter par colonne ?

Surtout pour éviter la traversée de cache de la mort et s'assurer de l'absence d'alias.

 
en fait j'ai jamais eu le temps de tester ces bibliothèques, j'ai été voir sur le site blitz++ et d'apres les tests affichés ca à l'air pas mal en effet (concurrence fortran 90+ et son support natif des expressions vectorielles), j'ai vu qu'il y avait aussi une MTL (Matrix Template Library) en fait il y en pas mal dans le domaine du calcul scientifique

 
qu'est ce que tu entends par "traversée de cache de la mort" et par "l'absence d'alias" ?

 
Pour l'avenir, les SELL et notament "the pivot" pour le calcul scientifique. Gaby aux manettes.

 
m'a trompé ^^  

 
Je fais que de ça depuis 3 ans et je peut te dire que les perfs ont VRAIMENT etonnantes.

 
matrix<double> a, b, c, d;
a = b * c + d;
un compilateur C++ va te générer :
tmp[i][j] = b[i][k] * c[k][j];
 
puis :
tmp2[i][j] = tmp[i][j] + d[i][j];
 
, et enfin :
a[i][j] = tmp2[i][j];
 
on aurait aimé qu'il génère  
tmp[i][j] = b[i][k] * c[k][j] + d[i][j]
a[i][j] = tmp[i][j];
afin de maximiser la localité. Ce que les expressions templates peuvent générer.
Dans le cas contraire, il traverse le cache autant de fois qu'il y a d'opérateurs, ce qui est mortel
 

Et la, tu te poses la question : pourquoi diable utiliser tmp, et recopier dans a ?
Et bien contrairement à un compilateur Fortran, un compilateur C++ n'est pas autorisé à supposer que a[][] est sans alias.
le les operateurs + et * précédent doivent pouvoir fonctionner si on a les expressions suivantes :
a = b * a + d;  (1)
a = b * c + a;  (2)
 
à l'évidence, a[][] est aliasé par lui même, sans utiliser un temporaire, (1) ne donnera pas le bon résultat.
(2) donnera sans doute le bon, mais un compilateur n'est pas autorisé à supposer que tu fais une addition parce que tu utilises operator+
Et plus fort encore si a[][] possede un pointeur dans sa representation interne, qui pointe vers la meme zone que b[][], même problème. Le compilateur ne pourra pas le savoir, sera pessimiste, et utilisera un temporaire.
 
restrict est la réponse à l'aliasing de C99. Pour C++, valarray, ublas, blitz++ utilise des extensions, genre __restrict généralement proposée, en attendant une meilleure solution.
au bout du compte, on peut arriver à générer ça :
a[i][j] = b[i][k] * c[k][j] + d[i][j];
si on est capable de garantir le non-aliasing -- et accessoirement, proposer une interface la moins unsafe possible.
 
 
 

 
oui ok, c'est ce que j'entendais par "construire des expression templates", enfin il me semblais que le but était toujours  d'éviter (dans le cas d'expression vectorielle avec plus de 2 opérandes j'imagine) le découpage (comme tu le montre) de l'expression et la création de vecteurs temporaires. les expressions templates permettent de reconstruire une expression vectorielle au niveau scalaire et n'avoir plus que de simple variables scalaires temporaires (qui sont inévitables)
 
je penses que tu aurais du dire
matrix<double> a, b, c, d;
a = b * c + d;  
 
vas générer
tmp1 = b * c;
a = tmp1 + d;
 
et avec les expression templates on aura directement
tmp1[i][j] = b[i][j] * c[i][j];
a[i][j] = tmp1[i][j] + d[i][j];
 
ca serait pas plutot ca ? (en fait je suis pas sur par rapport à ton histoire d'aliasing, faudrais plus de temp)
 
 

 
ok, en fait j'avais jamais percuter ca, vive le fortrant quoi

 
Je ne comprends pas.
 

 
Si tu veux.
 

 
Non. Le but est de traverser le cache une seule fois ( ie boucler sur i et j ), pour toutes les operations. La, tu traverses le cache une fois pour * et une fois pour +.  
De plus, rien ne prouve que a soit sans alias (par d par exemple). Le compilateur n'est pas autorisé à générer la deuxième ligne sans temporaire.
 
 

Disons que c'est fait pour.  

 
voir le topic de JoelF -> http://forum.hardware.fr/hardwaref [...] -39989.htm
ce que je dis c'est bien équivalent à ca

 
tout a fais
 

 
c'est ce que je voulais exprimer par
tmp1 = b * c;
a = tmp1 + d;
 
et quand j'ecris
tmp1[i][j] = b[i][j] * c[i][j];
a[i][j] = tmp1[i][j] + d[i][j];  
ca ve dire qu'on ne parcour qu'une seule fois ces vecteurs
 
pour l'histoire du k et du parcour different de b et c c'est pour calculer le produit matriciel ?
 

 
Moi aussi, tu remplace matrice par vecteur et le compte y est.
 

 
OK, on avait pas les mêmes notations, j'utilisait la notation d'einstein (des indices répétées) utilisées en mathématiques :
Aij = Bik . Ckj
k n'apparait que d'un coté, il est donc en sommation.
i et j apparaissent des 2 cotés : pour tout i, pour tout j.
 
 

Oui.

 
Je reviens la dessus pour éviter la confusion.

est équivalent à  
 
a[i][j] = b[i][k] * c[k][j] + d[i][j]; (notation des indices répétées)
 
et vu que tu ne peux pas garantir que a[][] est sans alias, c'est faux.

Dans EVE 2 , j'ai carrement retirer le produti matriciel des operatuers envoyant des expressions :s

 
La variable value ou dumoins la dépendance du pixel courantr avec le précédent est CRUCIALE pour ce type de filtrage, donc, je dois le conserver.
 
mais comme dans la discussion beaucoup abordent l'idée de lancer les calculs sous fome matricielle/vectorielle, ca me fais me demander,  
=>peut on réaliser ces calculs sous forme vectorielle :
 
soit remplacer l'expression :
 

par quelques chose comme (là, je ne donne pas la bonne syntaxe car je ne la connais pas encore...je veux d'abord savoir si ca peut valoi le coups
 

 
si tu veux vraiment optmiser faut pas ce genre de truc, et c'est possible en faisant le traitement par colonnes (et donc en réorganisant les données), lis bien les reponses qu'on te donnes