Discussion :

[r0d]

Bonjour � tous,

c'est plus une discussion qu'une question � proprement parler, mais j'aurais bien aim� avoir votre avis l�-dessus:

Le contexte:
Une application temps r�el, donc grosse contrainte de rapidit� d'ex�cution. Pas de contraintes particuli�res sur la gestion de la m�moire ni la compilation.
Plateforme: windows
Compilateur: celui de visual 2005 (mais cela n'a pas d'importance je pense)
Biblioth�que: STL si besoin est.

La probl�matique:
J'ai une boucle du type:

Code :

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

1
2
3
4
5
6
7
while (!MustStop) //MustStop est modifié par un autre thread
{
    int iBuffSize;
    short* source_buffer = GetBuffer(&iBuffSize);
 
    //Et là, je dois copier le buffer et faire des traitements sur la copie
}

- Je ne connais pas la taille du buffer que je vais r�cup�rer avant chaque it�ration,et cette taille est variable.
- La fonction GetBuffer(int &iBuffSize) me renvoie l'adresse du premier �l�ment du buffer et me donne sa taille (iBuffSize).
- Je dois absolument r�cup�rer le buffer (le copier) car je ne dois pas modifier le buffer d'origine.

Question
O� et comment allouer le buffer dans lequel je vais copier mes donn�es? Comment optimiser l'allocation?


J'esp�re que je suis suffisamment clair. Si ce n'est pas le cas, je me ferais un plaisir de re-expliquer tout �a.

Toute remarque est la bienvenue; merci pour votre participation

[Alp]

Alors si tu vas r�cup�rer que des short, tu peux utiliser une std::list de short, ou une std::deque. Enfin un conteneur standard quoi.
Sinon, hmm ... ben moi j'utiliserais un conteneur standard

[roulious]

Comme d'habitude, tout d�pend des traitements. Je te conseille de regarder des conteneurs standards, en choisir un en fonction des op�rations que tu vas devoir faire dessus, et regarder si la vitesse d'ex�cution te suffit. Si c'est le cas, pas la peine de chercher plus loin, sinon tu es probablement bon pour recoder les conteneurs. Dans ce cas, si tu peux garder une interface similaire � la SL (it�rateurs, nom des fonctions, ...), �a pourra �tre utile si tu veux r�-utiliser le code dans un autre projet.

[Alp]

En effet.
Mais en principe les conteneurs standards sont assez rapides, donc � mon avis cela devrait suffir.
Tiens nous au courant.

[Jean-Marc.Bourguet]

Je commencerais par chercher � changer l'interface pour ne pas avoir besoin de copies. Normalement on a un pool de buffer et les threads se passent la propri�t� du buffer.

Sinon,

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
std::vector<short> myCopy;
while (!MustStop) //MustStop est modifié par un autre thread
// il faudrait alors ce qu'il faut pour être assuré que MustStop n'est pas
// gardé en cache ou dans un registre...
{
    int iBuffSize;
    short* source_buffer = GetBuffer(&iBuffSize);
 
    if (myCopy.size() < iBuffSize) {
       myCopy.resize(iBuffSize);
    }
    memcpy(&myCopy[0], source_buffer, iBuffSize*sizeof *iBuffSize);
    // je te laisse le traitement
}

[mat.M]

Plateforme: windows

Faut prendre des API sp�cifiques Windows comme GlobalAlloc ;

[David Fleury]

<pinaillage>

Le contexte:
Une application temps r�el, donc grosse contrainte de rapidit� d'ex�cution. Pas de contraintes particuli�res sur la gestion de la m�moire ni la compilation.
Plateforme: windows

Le contexte et la plateforme sont rigolos.

Le 'temps r�el' suivi de 'donc ... contrainte de rapidit�' est un raccourci
� la mode alors on ne dira rien il est trop tard ce soir

</pinaillage>

[M�dinoc]

Faut prendre des API sp�cifiques Windows comme GlobalAlloc ;

Ici, je ne vois pas trop pourquoi...


PS: Au passage, Windows n'est pas un "OS temps-r�el".

[r0d]

Bonjour � tous,

merci beaucoup pour vos interventions.
Alors voici quelques pr�cisions (et modifications).

La boucle ressemblerait, en fait, plut�t � cela:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
while (!MustStop) //MustStop est modifié par un autre thread
{
    int iBuffSize = GetSize(); //donc on connais la taille avant de récupérer le buffer
    float* source_buffer = GetBuffer(iBuffSize); //c'est un tableau de float finalement :s
 
   // le traitement, qui contient un appel du style:
   UneFonction(myCopy, iBuffSize); //qui modifie MyCopy, 
   // cette fonction fait partie d'une lib que je ne peux pas modifier.
   // Elle prend un float* en paramètre
}

Alors donc, que pensez-vous de ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
std::vector<float> myCopy;
while (!MustStop) //MustStop est modifié par un autre thread
//c'est géré en amont, je ne m'occupe pas de cela :)
{
    int iBuffSize = GetBugffSize();
    float* source_buffer = GetBuffer(iBuffSize);
 
    if (myCopy.size() < iBuffSize) {
       myCopy.resize(iBuffSize);
    }
    memcpy(&myCopy[0], source_buffer, iBuffSize*sizeof *iBuffSize);
 
    UneFonction( (float*) myCopy, iBuffSize ); //ceci devrait fonctionner non?
}

[r0d]

Sinon, pour le temps r�eel, c'�tait un raccourci, en effet. Pour �tre plus pr�cis, je devrais dire: il y a plusieurs threads qui tournent et effectuent des traitements. Chacun d'entre eux doit �tre le plus rapide possible car nous devons assurer une vitesse minimale de traitement, qui est celle du temps r�el, et qui risque d'�tre difficile � assurer au vu du nombre important de t�ches � accomplir.

[rigobert]

petit d�tail qui peut avoir son importance :

Code :

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

float* source_buffer = GetBuffer(iBuffSize);

serait avantageusement remplac� par :

Code :

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

const float* source_buffer = GetBuffer(iBuffSize);

pour :

+ de clart�,
+ de s�curit�,
+ d'opportunit�s d'optimisations pour le compilateur.

[mat.M]

Ici, je ne vois pas trop pourquoi...

C'est tr�s simple et cela s'explique ais�ment : si on utilise des fonctions Windows la gestion de la m�moire en sera meilleure car c'est l'OS qui d�termine les strat�gies � adopter ( allocation de pages ).
cf "Programming Windows Nt" de Jeffrey Richter.
Avec des simples new il n'est pas exclu que la m�moire se fragmente..
Mais faut-il pr�ciser que utiliser des API c'est seulement dans le cas de grosses allocations.
Pour des petites allocations cela n'en vaut pas la peine..

PS: Au passage, Windows n'est pas un "OS temps-r�el".

Je sais merci mais �a faut dire cela � R0d.
Qu'il prenne un autre OS comme Qnx ou je ne sais quoi.

Question
O� et comment allouer le buffer dans lequel je vais copier mes donn�es? Comment optimiser l'allocation?

C'est exclusivement l'OS qui prend �a en charge...
Tu pourras toujours faire un new et obtenir un pointeur sur une zone m�moire apr�s l'OS va faire sa propre cuisine quoique tu fasses....

while (!MustStop) //MustStop est modifi� par un autre thread

Voir les sections critiques , les API EnterCriticalSection et InterlockIncrement