Discussion :

[BNS]

Bonjour � tous,

Je travaille sur un tableau de 307200 valeurs (640*480) �gales � 1 ou 0. Un pointeur me permet de jongler avec les diff�rents �l�ments du tableau. Dans un premier temps, j'avais d�clar� ce beau monde en int mais j'ai rapidement remarqu� que je pouvais gagner un gros temps d'�x�cution si je travaillais avec des unsigned char. Et maintenant je me dis qu'avec des booleens ca pourrait aller encore plus vite, je me trompe?
Ma questionm, en gros, c'est: lors d'une gestion d'un tableau de cette taille, qu'est-ce qui est le plus int�ressant d'utilisation? unsigned char? int? bool? autre?
Merci d'avance pour votre aide et vos conseils

[r0d]

Bonjour,

si mes souvenirs sont bons, cela d�pend du compilateur. Quel est celui que tu utilises?

Il y a �galement autre chose � prendre en consid�ration, c'est l'utilisation de ton ton tableau. Si par exemple tu fais un tableau de bool mais que, lorsque tu utilise ces valeurs, tu doit les caster en int, autant utiliser directement des int.

[BNS]

je travaille avec Visual Studio .NET 2003
J'utlise mon tableau de la facon suivante: selon qu'une case est � 0 ou 1, je noircis ou non une case (simple binarisation en fait), plus quelques autres trucs � cot�. En gros, j'utilise principalement:

Code :

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

1
2
3
4
5
 
if (Mask[i]==1) 
{
   fais moi ca;
}

[Pragmateek]

"char" est le plus petit type du C++.
Apr�s pour travailler au niveau des bits on peut utiliser les op�rateurs bitwise.
On �conomise de la place mais on perd en performance lors de l'acc�s aux bits des donn�es.

[r0d]

L�, il nous faudrait l'avis d'experts en optimisation, mais je crois que le type int est le plus (le mieux) optimis� en c++.

pr�f�rer le type int, c'est quasiment par d�finition le plus rapidement manipul� par le processeur.

Ca veut dire que bool ne peut pas etre manipul� rapidement par le proc?
L'important c'est tout de meme la proprete des types manipul�s par le programme, le compilateur fait sa sauce derriere pour arranger ca au mieux.

Je veux dire:
Si le type n'est pas soumis � une contrainte particuli�re, comme initialis� par tel autre type, pass� a une fonction, surpasser ou pas, avoir des d�cimales, �tre sign� ou pas...
...alors, il faut prendre int.
Prendre un type plus petit en se disant "il prends moins de place en m�moire, j'y gagne" risque surtout de forcer le compilateur � g�n�rer du code suppl�mentaire, ou � utiliser des instructions processeur anciennes pour y acc�der conform�ment au code �crit.

Hope it helps.

[BNS]

C'est en effet ce que j'ai lu un peu partout... Mais dans les faits, quand je travaille en int c'est plus lent qu'en unsigned char. Est-ce que la remarque que tu cites est principalement valable pour un petit nombre de valeurs?
Car la, avec 307200 valeurs, dans la memoire ca donne ca:
int ---> 1.228.000 bytes, soit 1.23 Mb
unsigned char ---> 307.000 bytes soit 0,31 Mb

[Foobar1329]

Hello,

Bonjour � tous,

Je travaille sur un tableau de 307200 valeurs (640*480) �gales � 1 ou 0. Un pointeur me permet de jongler avec les diff�rents �l�ments du tableau. Dans un premier temps, j'avais d�clar� ce beau monde en int mais j'ai rapidement remarqu� que je pouvais gagner un gros temps d'�x�cution si je travaillais avec des unsigned char. Et maintenant je me dis qu'avec des booleens ca pourrait aller encore plus vite, je me trompe?
Ma questionm, en gros, c'est: lors d'une gestion d'un tableau de cette taille, qu'est-ce qui est le plus int�ressant d'utilisation? unsigned char? int? bool? autre?
Merci d'avance pour votre aide et vos conseils

Pourquoi ne pas utiliser un tableau d'unsigned char de taille TailleMaxi / CHAR_BIT ? Si CHAR_BIT vaut 8 sur ton impl�mentation (cf <climits> ou <limits.h> ) comme c'est le cas pour beaucoup, tu peux avoir le bit comme donn�e �l�mentaire et surtout diviser la taille de tableau par 8. Si en plus ta taille maxi est un multiple de 8 comme ici, c'est facile.

Voici un exemple de code ci-dessous. C'est un exemple crado pour aller vite. Tu peux bien s�r virer la variable globale, d�finir par exemple un type (classe, structure) sur lequel tu pourrais effectuer des manipulations de bits en y mettant des fonctions membres qui font la m�me chose que les 2 pr�sent�es en dessous, lever des exceptions si l'utilisateur rentre une position erron�e, etc...

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
#include <climits>
#include <iostream>
 
#if (CHAR_BIT != 8)
#error "CHAR_BIT doit valoir 8 pour compiler et exectuer ensuite le code ci-dessous"
#endif // (CHAR_BIT != 8)
 
const int cMaxSize = 640*480;
 
unsigned char foobar[cMaxSize/CHAR_BIT];
 
int setBitAtPos(const int & pos, bool bVal)
{
   int rc = -1;
   if (pos>=0 && pos<cMaxSize)
   {
      int numBlock = pos / CHAR_BIT;
      int posInBlock = pos % CHAR_BIT;
      unsigned char * pBlock = foobar;
      pBlock += numBlock;
      unsigned char mask = 1u << posInBlock;
      if (bVal) {
         *pBlock |= mask;
      }
      else {   
         *pBlock &= ~mask;
      }
      rc = 0; 
   }
   return rc;
}
 
int getBitAtPos(const int & pos) 
{
   int rc = -1;
   if (pos>=0 && pos<cMaxSize)
   {
      int numBlock = pos / CHAR_BIT;
      int posInBlock = pos % CHAR_BIT;
      unsigned char * pBlock = foobar;
      pBlock += numBlock;
      unsigned char mask = 1u << posInBlock;
      rc = (*pBlock & mask);
   }
   return rc;
}
 
int main()
{
   int rc = 0;
 
   std::cout << "Number of elements in foobar: " << cMaxSize<< "\n" ;
   std::cout << "Size of foobar: " << sizeof(foobar) << " bytes.\n" ;
 
   rc = setBitAtPos(300000, true);
   rc = getBitAtPos(300000);
 
   rc = setBitAtPos(0, true);
   rc = getBitAtPos(0);
 
   return 0;
}

A+

[Jean-Marc.Bourguet]

Ma questionm, en gros, c'est: lors d'une gestion d'un tableau de cette taille, qu'est-ce qui est le plus int�ressant d'utilisation? unsigned char? int? bool? autre?

Ca va d�pendre principalement du processeur utilis� et accessoirement du compilateur et de la mani�re dont tu vas �crire le code.

Le premier effet dont il faut tenir compte est le cache. Moins les donn�es occupent d'espace, plus il y a de chance qu'elles soient dans un cache proche (les processeurs peuvent avoir plusieurs niveaux de cache) quand on en a besoin. Donc plus on a des donn�es denses, plus on va vite.

Mais cet effet est contrebalanc� par un autre facteur: les calculs n�cessaires pour acc�der aux donn�es. Les processeurs qui peuvent acc�der � un bit individuellement sont rares (et il est de plus difficile de faire comprendre � un compilateur qu'il faut utiliser ces instructions), donc on va y acc�der par masquage de donn�es plus grosse. C'est parfois vrai aussi pour les char (mais c'est moins courant). Ces instructions ont un co�t, il est donc possible qu'il soit plus important ou plus faible que le gain d� � la moindre occupation m�moire.

Le facteur suivant est le compilateur. S'il est capable de remarquer que tu utilises syst�matiquement les 8 bits d'un octet apr�s l'avoir lu, il va peut-�tre pouvoir utiliser une s�quence plus performante que de relire chaque fois l'octet, construire un masque d�pendant d'une variable et utiliser ce masque.

Le dernier facteur, c'est la mani�re dont le code est �crit. Je citais le cas d'un acc�s s�quentiel � tous les bits d'un octet, si tu �cris le code de mani�re � ce que ce soit bien remarquable, il y a plus de chances pour que le compilateur utilise une s�quence efficace. Tu peux aussi r�organiser le code de mani�re � faire plusieurs passes sur un bloc qui tient en cache avant de passer � un autre bloc de donn�es plut�t que de faire la premi�re passe sur toute les donn�es, puis la deuxi�me, ...

Il est fort vraissemblable qu'il y ait aussi des effets de seuils... jusqu'� une certaine taille utiliser un int est mieux, ensuite jusqu'� une autre utiliser un char est mieux, enfin utiliser un bit. Par exemple, le niveau de m�moire le plus lent est le disque (quand le SE commence a swapper). M�me s'il faut beaucoup d'instructions pour g�rer un stockage par bit, si �a permet d'�viter de swapper c'est � coup s�r un gain.

[Pragmateek]

Et les "bitset"?

[Jean-Marc.Bourguet]

Et les "bitset"?

C'est, en C++ (je ne sais pas pourquoi, je pensais r�pondre sur le forum C) une alternative � g�rer le masquage pour une taille fixe. Pour une taille variable, on peut utiliser un std::vector<bool> qui est sp�cialis� pour permettre une optimisation en espace.

D'un point de vue performance, comme dans les autres options il faut mesurer pour savoir ce qui est le mieux (donc commencer par d�terminer si c'est r�ellement critique) car ces solutions peuvent �tre meilleures ou pire qu'une gestion manuelle avec masquage.

En fait, en C++ l'utilisation d'un bitset ou d'un vector<bool> est vraissemblablement la solution � utiliser si on n'a pas mesur� qu'elle est trop co�teuse.