Discussion :

[RedSkidy]

Bonjour,
dans un projet je me retrouve dans un cas o� plusieurs fonctions pourraient s�appeler mutuellement et former un cercle :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
void fonction1(params){
  ...
  fonction2();
}
void fonction2(){
  ...
  userCallback(); //appelle userFunction()
}
void userFunction(){
  ...
  fonction1();
}

Evidemment le probl�me avec ce genre de code, c'est qu'il g�n�re une sorte d'arbre :
fonction1{
fonction2{
fonction3{
fonction1{
fonction2{
...
et puis au bout d'un moment stack overflow alors j'ai tout de suite oubli� l'id�e.
J'avais commenc� � g�rer �a avec des threads mais comme ce serais beaucoup plus simple et plus efficace de le faire avec la premi�re m�thode, je suis quand m�me all� chercher au cas o�... je suis tomb� sur une certaine "tail optimization", il semblerait que certains compilateurs transforment le "call" en "jump" quand l'appel est la derni�re instruction de la fonction, ce qui corrige le probl�me.
Oui je sais c'est pas ce qu'il y a de plus propre comme code mais c'est ce qu'il y a de plus rapide et contourner cette m�thode rendrais probablement le code 10x plus complexe.

Mais la question est (ou plut�t les questions) : Est-ce que �a marche dans mon cas ?
dans tous les exemple que j'ai trouv�, les fonctions n'�taient pas des "void", la derni�re ligne �tait donc toujours quelque chose comme "return fonction(p);" dans mon cas les fonctions sont de type void, est-ce que appeler la fonction suffit ou je dois �crire quelque chose comme "return fonction();"
J'utilise visual studio, est-ce que le compilateur r�alise l'optimisation ? si oui et-ce qu'il faut param�trer quelque chose avant j'avais vu qu'en g�n�ral l'optimisation de ne fait qu'en release, si c'est le cas peut-on la forcer ?

Merci de votre aide.

[Matt_Houston]

Toute r�cursion a besoin d'une condition d'arr�t. Soit ton algorithme est incorrect, soit c'est son impl�mentation qui l'est. Identifie cette condition et d�termine pourquoi elle n'est jamais v�rifi�e � l'ex�cution.

[RedSkidy]

Il y a une condition d'arr�t, en quelques sortes, quand l'utilisateur le d�cide en fait ce qui pourrait se faire au bout de 1 million de tour de boucle...
Mais c'est possible dans le cas ou le compilateur r�alise cette "tail optimization", le code compil� seras a peu pr�s �quivalent a un goto plut�t qu'un appel de fonction donc pas de probl�me de stack overflow

[Matt_Houston]

Je comprends ce que tu veux faire : tu te dis que tu peux peut-�tre t'�viter une refactorisation en profondeur en jouant sur cette rustine.

Pour b�n�ficier de la TCO il faut :

• que le code de chacune des x fonctions soit �ligible ;
• que l'impl�mentation prenne en charge cette optimisation (ce n'est pas garanti par la norme en C++, on perd donc d�j� en portabilit�).

Je ne connais ni ton cas d'utilisation, ni ton code (peut-�tre peux-tu nous en dire plus ? Et il faudra de toute mani�re y jeter un �il si tu veux avoir un avis technique) mais quand je lis �a :

Il y a une condition d'arr�t, en quelques sortes, quand l'utilisateur le d�cide en fait ce qui pourrait se faire au bout de 1 million de tour de boucle...

..je tique, cela ressemble � un choix d�sesp�r� pour r�pondre � un d�faut de conception. Peut-�tre faut-il remettre � plat une partie de cette derni�re ?

[RedSkidy]

Bon j'avoue ne pas avoir tout compris je suis assez nouveau dans le milieu de la programmation j'ai que 2 ans d�exp�rience si on peut appeler �a de l�exp�rience �tant donn� que j'ai appris tout seul sur internet donc j'ai encore un peu du mal avec le vocabulaire technique

En fait je suis entrain de faire (ou en tout cas d'essayer) une biblioth�que qui g�re des r�seaux de neurones (un �quivalent de tflearn mais en c++) qui fait les calculs sur GPU en utilisant OpenCL.
J'essaye de la concevoir pour qu'elle soit modulaire, facile d'utilisation et rapide.
J'ai une classe NetManager qui contiens diff�rents objets n�cessaires a OpenCL (context, platform, command_queue...) et un tableau de r�seaux de neurones.
Ces r�seaux de neurone contiennent eux m�me un tableau de "AbstractLayer" qui repr�sente les couches du NN.
Pour qu'OpenCL fasse un calcul, il faut lui envoyer une commande qu'il ex�cuteras d�s qu'il pourra. Quand l'execution est termin� il appelle une fonction callback.
Les commandes envoy�s ne sont pas forc�ment ex�cut�es dans l'ordre mais les couches elles doivent �tre "utilis�es" dans l'ordre.
alors j'ai une fonction appelons la "coordinate()" (pas trouv� de nom encore) qui va :
appeler la fonction "start()" de la couche 1, cette couche 1 va envoyer une commande a OpenCL et lui donner "coordinate" come callback
coordinate seras donc re-appel�e a la fin du calcul et va ensuite appeler la fonction start() de la couche 2 etc...
a la fin, elle appelleras une autre fonction callback d�finie par l'utilisateur cette fois, pour lui dire que son r�seau de neurone a termin�.
Et l'utilisateur va probablement lui donner de nouvelles instructions, ce qui re-appelleras la fonction coordinate...

Peut �tre qu'une rupture se fait au niveau de OpenCL qui doit surement appeler la fonction callback depuis un autre thread mais je ne sais pas si c'est une bonne id�e que presque tout le code soit ex�cute par un thread sur lequel je n'ai aucun contr�le et je ne sais pas si OpenCL continue de fonctionner pendant l'appel de la fonction callback

Ma solution alternative �tait d'avoir un thread qui v�rifie constamment l'�tat de tous les r�seaux de neurones et leur redonne une tache si n�cessaire, une sorte de fonction coordinate g�n�rale (pour tous les r�seaux) ex�cut�e dans un thread. La boucle resteras bloqu�e tant qu'une fonction "update()" n'auras pas �t� appel�e. cette fonction est utilis�e comme callback pour OpenCL. Le blocage sert a �viter d'avoir une boucle infinie qui utilise 100% du processeur

[Matt_Houston]

Je peux avoir compris de travers mais de ce que tu pr�sentes, les t�ches doivent �tre ex�cut�es de mani�re totalement s�quentielle. Pourtant tu as actuellement une call stack de la forme :

Code :

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

1
2
3
4
5
6
7
8
9
start(0)
  callback(0)
    start(1)
      callback(1)
        start(2)
          callback(2)
...
            start(n)
              callback(n)

Ma question est : pourquoi ? Pourquoi empiler tous ces contextes alors que la t�che n+1 ne peut d�marrer que lorsque la t�che n est termin�e ?

Le callback peut tr�s bien se borner � mettre le r�sultat dans une structure commune et lever un �v�nement pour signaler la fin de la t�che correspondante pour obtenir quelque chose du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
run()
  start(0)
    callback(0)
  start(1)
    callback(1)
  start(2)
    callback(2)
...
  start(n)
    callback(n)

Tu n'es m�me pas forc� d'utiliser plusieurs threads (hors ceux sur lesquels les callbacks sont invoqu�s, s'il ne s'agit pas du main thread).