Discussion :

[Flo.]

Bonjour,

j'ai un tableau d'unsigned short � 3 entr�es, par exemple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

unsigned short myTab[4][4][256 * 256];

Il tr�s important, pour mon utilisation, de garder cette notion de tri-dimensionalit�. Et lorsque je traite un tableau[i][j][256 * 256], je n'utilise pas les autres tableaux[x][y][256 * 256].

Je sais que l'utilisation de tableaux uni-dimensionnels est pr�f�r�e � des tableaux mutli-dimensionnels ; les temps d'acc�s aux �l�ments d'un tableau multi-dimensionnels sont plus longs.

Par contre, quelle est la meilleure solution ?

Cas n�1 : myTab devient un tableau uni-dimensionnel, et j'utilise des offsets pour acc�der aux parties qui m'int�ressent :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
unsigned short myTab[4 * 4 * 256 * 256];
 
int offset00 = 0;
int offset01 = offset00 +  256 * 256;
int offset02 = offset01 +  256 * 256;
int offset03 = offset02 +  256 * 256;
int offset10 = offset03 +  256 * 256;
//... etc ...
int offset33 = offset32 +  256 * 256;
 
// et pour accéder à mon "original" myTab[2][1][65]
myTab[offset21 + 65] = 8;

Par contre je risque d'encombrer le cache inutilement puisque, comme le l'ai dit plus haut, lorsque je traite un tableau[i][j][256 * 256], je n'utilise pas les autres tableaux[x][y][256 * 256].

Cas n�2 : je d�clare 16 tableaux de 256 * 256 que je r�unis dans un tableau de pointeurs :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
unsigned short myTab00[256 * 256];
unsigned short myTab01[256 * 256];
unsigned short myTab02[256 * 256];
unsigned short myTab03[256 * 256];
unsigned short myTab10[256 * 256];
unsigned short myTab11[256 * 256];
unsigned short myTab12[256 * 256];
unsigned short myTab13[256 * 256];
//... etc ...
 
// je réunis le tout dans une table de pointeurs
unsigned short * ptrOnMyTab[4][4];
 
ptrOnMyTab[0][0] = &myTab00[0];
ptrOnMyTab[0][1] = &myTab01[0];
ptrOnMyTab[0][2] = &myTab02[0];
ptrOnMyTab[0][3] = &myTab03[0];
ptrOnMyTab[1][0] = &myTab10[0];
//... etc ...
 
// et pour accéder à mon "original" myTab[2][1][65]
ptrOnMyTab[2][1][65] = 8;

Dans ce cas, je me demande si �a ne revient pas finalement au cas original myTab[4][4][256*256]

Alors qu'elle est la meilleure solution au final ?

Merci

Flo.

[ash.ice.loky]

Salut Flo,

A savoir qu�un l�op�rateur de pointage �quivaut � l�op�rateur d�indexation.
Mes 2 fa�ons de faire sont les suivantes :
- tableau unidimensionnel, avec d�calage.
- vetor<vector<vector> > > : notation assez lourde, mais avec un petit typedef le probl�me est r�gl�.

[Flo.]

Merci pour ta r�ponse ash.ice.loky.

Je voudrais juste rajouter que j'utilise mon tableau dans un contexte de temps r�el.

J'ai d�j� fait des tests sur les vectors (notamment dans des algorithmes de segmentation d'images pour remplacer des tableaux), et �a n'a pas �tait concluant. Donc je ne retiendrai pas cette solution.

Par contre pourrais-tu �tre plus pr�cis sur :

A savoir qu�un l�op�rateur de pointage �quivaut � l�op�rateur d�indexation

Quant aux 2 cas que j'�voque, ils ne sont quand m�me pas identiques :

Dans le 1er cas j'ai un tableau �norme � faire passer dans le cache (de taille 4*4*256*256).
Dans le 2eme cas, juste un tableau de 256*256 (si �a fonctionne bien ainsi !!!).

La mise en cache devrait �tre plus rapide donc. Mais je ne m'y connais pas trop dans ce genre de chose. Je ne sais pas si il y a vraiment un gain ou pas

Flo.

[Sivr�t]

A savoir qu�un l�op�rateur de pointage �quivaut � l�op�rateur d�indexation

Je pense que ce qu'il veut dire est que

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
unsigned short myTab[4][4][256 * 256];
cout << myTab[2][1][65];

est identique �

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
unsigned short myTab[4][4][256 * 256];
cout << *(myTab + (2*4 + 1)*256*256 + 65);

J'ajouterais que en m�moire on obtient le m�me r�sultat avec les deux d�clarations:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
unsigned short myTab[4][4][256 * 256];
unsigned short myTab[4*4*256 * 256];

Dans les deux cas c'est une seule zone avec la m�me taille. La seule diff�rence est qu'avec la deuxi�me il faut g�rer soit m�me les diff�rentes dimentions (sinon c'est le compilo qui le fait car on lui a donn� les infos).

Pour tenter d'optimiser il est toujours possible de poser

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
unsigned short * current = myTab[2][1];

et de travailler sur current pour �viter de multiplier les calculs d'indices. Mais le compilateur doit �tre capable de g�rer ce genre d'optimisations de lui m�me donc � r�server en dernier recourt.

Le vrai probl�me des tableaux � plusieurs dimentions est quand leurs taille s ne sont pas fixes. On passe par des tableaux de pointeurs, on fait des "new" et le tableau est �clat� en m�moire mais ce n'est pas le cas ici. De ce point de vue le cas 2 me semble une mauvaise id�e car il introduit un d�r�f�rencement de plus (� la diff�rence du cas original) et il fragmente les donn�es.


Je connais assez mal le fonctionnement des caches mais dans l'ensemble on tente plut�t de grouper les donn�es que de les fragmenter (m�me si ici l'ind�pendance des diff�rents morceaux limite cet aspect). Et il me semble que rien ne s'oppose � ce que seule une partie du tableau soit mise en cache. Si je ne me m�prend pas l� dessus les diff�rentes notations n'apporterons pas de gain (ou de perte) monumental de performances, alors "unsigned short myTab[4][4][256 * 256]" me semble avoir l'avantage d'�tre pratique et clair.

[Flo.]

Bon ben je vous remercie.

En fait, je vais passer � mon 1er cas :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
unsigned short myTab[4 * 4 * 256 * 256];

Parce que lorsque je dois "vider" (mettre � 0) tous les tableaux, je pourrais tout passer en une seule boucle XMMX. Ca sera d�j� un gain appr�ciable .

Merci.

Flo.

[Laurent Gomila]

Quoiqu'il en soit, essaye d'encapsuler tout �a dans une interface qui elle ne variera pas, de fa�on � ce que ton code soit toujours valide le jour o� tu souhaites changer la repr�sentation interne de tes tableaux.

[Sivr�t]

Parce que lorsque je dois "vider" (mettre � 0) tous les tableaux, je pourrais tout passer en une seule boucle XMMX. Ca sera d�j� un gain appr�ciable.

Ca marche aussi avec

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

unsigned short myTab[4][4][256 * 256];

qui est en fait la m�me chose. Dans les deux cas myTab va pointer sur le premier des unsigned short qui seront contigus donc MMX powa quand m�me. Je trouve dommage de renoncer � la facilit� de notation pour eviter un cast (d'ailleurs non n�cessaire je crois)

[Flo.]

Effectivement vous avez raison, j'ai r�fl�chi un peu rapidement.

Je vais pr�server ma notation originale, ce qui, vous avez tous enti�rement raison, est plus lisible ...

Merci encore.

Flo.

[loufoque]

Pour les tableaux � n dimensions il est plus pratique d'utiliser boost::multi_array