Boujour tout le monde,
Alors donc, je bosse dans le traitement d'image et la reco de forme, je suis pas franchement un wizard, le code tenant plus du moyen que de la finalité.  
Mais donc je suis confronté a ce petit probleme : pour le traitement d'image, de gros tableaux donc, j'avais tendance à favoriser l'acces par pointeur que par index.
C'est a dire considerer ca  

 
 
mieux que ca  

 
en debug sous VS2005 c'est vrai, mais je m'apercois qu'en release... la deuxieme version est juste deux fois plus rapide.
vive la prediction !
 
mais bon, en meme temps si maintenant je travaille sur un voisinnage, les deux versions suivantes sont strictement aussi rapide :

 
mais moins rapide (5%) que la version bourrin :
 

 
 
D'ou ma QUESTION :
Quelles sont les règles à observer avec les compilo moderne pour optimiser les temps de calcul???
 
 
Toute les remarques sont les bienvenues

Je te conseillerais de mater du côté de comment le compilo de 2005 optimise le code, voire aussi de celui des post/pre incrementations.
 

Oui merci, je vais regarder ça de plus pres.
Sinon pour la preincrementation, d'apres les tests, c'est aussi à ranger dans la catégorie vielle légende.
PS : one sait jamais , des liens pour des doc sur le compilo 05?
Marci en tout cas

arrete d'utiliser cette notation 1D pour l'accés au élément et fait comme les grandes personnes : utilise une notation  2D aprés une allocation façon NRC.

Ensuite, la tu bouibouite pour rien. Tu gagnera vraiment en optimisant la localité de tes données dans le cache, càd en travaillant sur des tuiles carrées au sein de ton image.
CF le topic : http://forum.hardware.fr/hfr/Progr [...] 0227_1.htm
Ensuite, ca te permet aussi de parcourir des voisinages proprement

Ah et ICC >> Visual Crap 2005 Faudra voir à utiliser le compilo qui correspondt à ton archi et pas un ersatz

ICC , ca me rappelle un certain Lacassagne, me demande s'il est pas à Orsay lui aussi. Mais oui sur le principe oui. Mais apres.
NRC : faudrait que je m'y remette. en ce moment je suis plus sur OpenCV. (Qui est lui aussi basé sur les lib Intel mais qui ne pratique pas l'index 2D sauf erreur.)
Les index 2D : ah ouais t's raison il faut que je grandisse!!!
Plus serieusement je comprends pas bien : une alloc 1D garantie une certaine continuité dan le cache nan?
et puis tu dis dans l'autre thread que tu sauves un Multiplication a chaque acces. Perso moi de mon cote ca fait une multiplication +une addition mais seulement 1 fois par ligne. apres c'est gratos. ca me semble mieux ou alors j'ai pas compris.  
 
Mais sinon tres merci de ton attention que je suppute tres documentée. Dans l'attente d'une réponse !

Ouasi, il est genre dans le bureau d'en face là
 

 
Regarde comment j'alloue : 1 bloc contigue de N*M puis un bloc de pointeur de M qui pointe sur le debuts des lignes. Tout est contigue.  
Pour assurer la localité dans le cache, c'ets pas tant le fait d'etre contigue. On demontre mathematiquement que la zone memoire qui optimise la localité, c'est une boule. Dans le monde des caches, les boules, c'est des carrés
Ensuite, l'acces [][] simplifie grandement la description de la boule optimale et c'est la ou y a le gain.

bon ben passe lui le bonjour de la part de celui qui lui a optimisé une multiplication matricielle a Jussieu.
 

Alors qu'elle implique une addition a chaque acces????
 

compare à comment tu ecrirais ton parcours de tuile carré avec ton accés 1D.
 

 
Salut, C'est "Lacassagne", j'hésite entre 2 personnes: 1 qui était bonne à CS et l'autre à peine moyenne en frag...
Si tu veux avoir des info sur le compilo Intel, j'ai une vielle version de l'aide en ligne sur ma page: http://www.ief.u-psud.fr/~lacas
 
Je retrouve mon login sur Hardware et je te poste la suite.
Je suis neanmoins surpris que, quelques années apres mon départ de Jussieu, plus personne ne sache coder ;-)
 
L.

E.

 
Alors si on neglige le calcul des i+j*M en debut de ligne et stockés en variables intermediaires, chaque acces va me couter une addition pour parcourir le voisinnage tab[a-1]..tab[a+1], tab[b-1]..tab[b+1]... et toi Deux ;tab[i-1][j].... puisque qu'une intervient a chaque calcul d'adressede toute facon..
Apres j'admets que mon code sera du type " a gerber" genre le dernier exemple que je donnais a la fin de mon premier message
 
Combien de PS3 a la maison les celleux?  

tab[i][j] ne fait que une addition ... je vois pas ou est la deuxieme

 
Tu veux dire R1 ?
 
En ce qui concerne les compilos, c'etait au 19eme siecle qu'on utilisait la notation pointeur, parce qu'a l'epoque les compilos etaient franchement mauvais.
Maintenant, cela va mieux et l'idee c'est de se rapprocher le plus possible du F77 et de ses notations tableaux, d'ou T[i][j].
Apres, dans le choix du compilo, sur intel et AMD: icc, sur Power, XLC.
 
Apres tu peux derouler ta boucle, faire de la rotation de registres, et d'autre trucs sympa. Sur des noyaux de convolutions, en passant en SIMD, on jusqu'a un gain x30 a x40 (si si) en combinant differentes technique.
 
en ce qui concerne les problemes de codage en OpenCV, il faut transformer les pointeurs 1D en pointeurs 2D via une structure NRC, ce qui resoudra ton pbm
 
L.

tab[i][j] ouais alors ok 1 addition pour le parcours , mais alors moi tab[k] et dans ce cas zero (encore une fois je neglige le k=i+j*M en debut de ligne): mais decidément je crains le quiproquo.  
 
 

Je vais ptet faire ca ouais. Merci.
Ptain vous vous etes bien trouvé tout les deux
 
R1(donc)

 
Les grands esprits se rencontrent. Pour info, il y a actuellement en France un regroupement de ce type de competences (et d'autre ofc) via les Poles de Competitivité qui combine l'approche industrielle (R&D) avec les Labos de Recherche. Passe donc sur les sites web d'Ocelle (http://ocelle.ief.u-psud.fr) et de Teraops (http://teraops-emb.ief.u-psud.fr)
 
Avec l'explosion de la complexité des algo, on est de plus en plus obligé d'optimiser les codes. Ceux qui ne le font pas vont disparaitre a terme...
Idem pour le hard.
 
Nous on developpe des outils pour que justement il ne soit plus necessaire de maitriser le codage en C et connaitre toutes les techniques d'optimisation.
Car une fois que ton code tourne sur 1 proc, il faut distribuer le calcul sur p procs (par exemple deux quadri-core). Et la c'est NP complet...
 
L.

"Et la c'est NP complet" : toujours le mot pour rire à ce que je vois

 
OK, explosion combinatoire.
 
T'es dans quelle boite ?

Houla c'est complique :
j'ai fait un an pour le LCPC, 3 mois pour le LIVIC via une chtite boite, et comme ils sont cool, j'y reste un peu. ils lancent une micro filiale vision/ reco de la route. on est 2 pour l'instant. on va bosser sur LOVE un petit peu.
 mais sur laval .bref dans 5 6 mois j'avise.

typiquement pour Love (http://love.univ-bpclermont.fr/ pour ceux qui nous lisent), il faut des outils car les algos sont compliqués et nombreux.
si pour le moment, on se contente de faire tourner cela en mono thread, la version finale devra etre optimisée et parallelisee...
 
Donc il faut y penser des maintenant pour que ton code soit parallelisable. Avec NRC ca l'est avec des pointeurs ce sera bien plus difficile...
 
L.