Discussion :

[oodini]

Hello,

Pour l'impl�mentation d'un tableau d�chiquet�, l'utilisation de vecteurs de vecteurs, plut�t qu'une tambouille � base de tableaux de pointeurs, repr�sente--t-elle une baisse significative de performances ?

Seules les performances en lecture m'int�ressent. Le remplissage est d�terministe, et n'induira pas de probl�me de r�allocation.

[Neckara]

Bonjour,

Je pense que la meilleure solution reste encore de tester

Apr�s, "baisse significative de performances" d�pend surtout de ce que ton programme fera et du nombre de donn�es qu'il manipulera.

Si tu t'amuses � lire des fichiers tout en ayant une interface graphique 3D et que tu ne manipules que 4 valeurs, prendre un tableau de pointeurs ou un vecteur de vecteur ne fera pas grande diff�rence.

Par contre si ton programme ne fait que lire les donn�es de ton vecteur de vecteur ou de ton tableau de pointeur et que tu as un nombre important de valeurs � traiter alors oui, peut-�tre que cela pourra jouer.

[oodini]

Pour l'instant, il y a un tableau de pointeurs qui m'emm�nent quelque part sur un m�me tableau d'octets. L'�l�ment point� me donne le nombre d'�l�ments auquel je dois m'attendre, puis j'it�re sur les octets suivants (modulo une taille de classe : c'est de la d�s�rialisation) avec un passage par un reinterpret_cast().

J'ai plut�t envie, � la lecture, de transformer tout �a en un vecteur de vecteurs.

[Joel F]

un vecteur de vecteur n'est pas contigu et va pourrir ton cache

[Neckara]

Sinon, c'est un peu tir� par les cheveux, mais ne pourrait-on pas stocker toutes les donn�es dans un seul vecteur "data" comme tu le fait avec ta m�thode de tableau de pointeur puis cr�er un vector de Ligne contenant des Lignes.

Une Ligne h�riterait alors de vector et red�finierait les m�thodes de sorte qu'il aille rechercher les donn�es dans le vecteur "data" � chaque demandes (DP Proxy je ne m'abuse).

Ainsi tu ne devrais pas trop perdre en performances et tu aura un conteneur "STL".

[Iradrille]

Une Ligne h�riterait alors de vector et red�finierait les m�thodes de sorte qu'il aille rechercher les donn�es dans le vecteur "data" � chaque demandes (DP Proxy je ne m'abuse).

L'h�ritage et les conteneurs STL, �a va tr�s mal ensemble, les destructeurs ne sont pas virtuels.

[backlash]

Un seul vecteur r�sout compl�tement le probl�me sans perte de performance!

[Neckara]

L'h�ritage et les conteneurs STL, �a va tr�s mal ensemble, les destructeurs ne sont pas virtuels.

J'avais oubli�

Il n'y a peut �tre pas besoin d'h�ritage alors, je sais que les it�rateurs doivent h�riter de pas mal de choses ( mais il suffit d'utiliser ceux du vecteur "data"), mais pour les conteneurs je ne suis pas s�r que ce soit le cas.

[Kalith]

L'h�ritage et les conteneurs STL, �a va tr�s mal ensemble, les destructeurs ne sont pas virtuels.

... ce qui n'emp�che pas d'utiliser l'h�ritage priv�, de rendre publiques les m�thodes de std::vector que l'on souhaite exposer, et d'impl�menter sois-m�me celles qui ont un comportement diff�rent de la base :

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
template<typename T>
class Ligne : private std::vector<T> {
    using base = std::vector<T>;
 
public :
    using base::iterator;
    using base::const_iterator;
    using base::reverse_iterator;
    using base::const_reverse_iterator;
 
    using base::begin;
    using base::end;
    using base::rbegin;
    using base::rend;
 
    // ...
 
    T& operator [] (std::size_t i) { ... }
    const T& operator [] (std::size_t i) const { ... }
}

[Iradrille]

... ce qui n'emp�che pas d'utiliser l'h�ritage priv�

ok, je connaissais pas �a, �a peut �tre utile dans pas mal de cas, merci =)

[Bousk]

L'h�ritage et les conteneurs STL, �a va tr�s mal ensemble, les destructeurs ne sont pas virtuels.

Ce qui ne d�range que si tu comptes utiliser ton container avec du polymorphisme
Ecrire class MyVector : public std::vector ne g�ne en rien tant que tu ne manipules par MyVector comme �tant un std::vector, mais uniquement des MyVector
Ca revient plus ou moins � se limiter � l'h�ritage private dans son utilisation, moyennant un minimum d'attention du programmeur.
C'est pas forc�ment du plus propre, mais quel gain de temps on peut gagner

[oodini]

Bonjour,

Ce que vous proposez est int�ressant, mais je n'ai malheureusement pas le temps pour l'impl�menter.

Je vais donc en rester � l'existant pour �viter les probl�mes de manque de localit� des donn�es.

[oodini]

En fait, comme je compte mettre mes vecteurs en m�moire partag�e, o� la m�moire allouable est contrainte dans un espace r�duit, je ne devrais finalement pas �tre confront� au probl�me de la localit� des donn�es.

[ternel]

Attention, pas de pointeurs dans la m�moire partag�e.
(des pointeurs vers elle, ok, mais pas dedans)

[oodini]

Boost.Interprocess offre un pointeur intelligent bas� sur un offset pour g�rer l'utilisation des pointeurs.

[Neckara]

Attention, pas de pointeurs dans la m�moire partag�e.
(des pointeurs vers elle, ok, mais pas dedans)

Si des pointeurs dans la m�moire partag�e pointent vers une zone de cette m�me m�moire partag�e est-ce qu'il y a vraiment un probl�me ?
Je pense que non mais je commence � avoir un doute

[oodini]

Je d�bute dans le domaine, mais d'apr�s ce que j'ai cru comprendre, il n'y a pas moyen de travailler avec des pointeurs, quelle que soit leur forme, entre deux zones m�moire.

Si c'est au sein de la m�me zone m�moire, il faut utiliser un pointeur sp�cial, sauf si c'est un seul et unique processus qui travaille avec ces pointeurs.

[ternel]

les m�moires partag�es sont "mapp�s" vers des blocs de m�moires internes � chaque processus.
ainsi, la "shared adress 17" peut �tre � l'adresse 134 pour process1 et 812 pour process2;

&"shared adress 17" = 134 dans process1 et &"shared adress 17" = 812 dans process2

dans process1, stoquer l'adresse 134 dans un pointeur partag� ne le traduit pas pour process2.

[Emmanuel Deloget]

Si des pointeurs dans la m�moire partag�e pointent vers une zone de cette m�me m�moire partag�e est-ce qu'il y a vraiment un probl�me ?
Je pense que non mais je commence � avoir un doute

Pas possible. La zone m�moire peut �tre mapp�e � deux adresses diff�rentes (0x7000a000 et 0x7000b000 par exemple) dans deux process diff�rents. Du coup, un pointeur 0x7000a110 dans la zone de m�moire partag�e ne pourra pas �tre utilis�e dans la seconde.

offset_ptr<> dans boost.interprocess stocke l'offset entre l'objet offset_ptr<> et la cible - donc, dans le cas des deux exemple, si (p = this = 0x700a100 = 0x10), offset. Le d�r�f�rencement de offset_ptr<> effectue l'op�ration inverse. Sur la seconde zone, (p = this = 0x7000b100, donc *p = (0x7000b100+offset) = 0x7000b110.

Il y a des petites astuces sur la copie, le move... pour que l'offset reste toujours valide quelque soit l'instance de offset_ptr<> consid�r�e.

C'est la seule mani�re de proc�der (mani�re � laquelle je n'avais pas pens�, d'ailleurs).