[Index Software] Coin des développeurs :]

[Bubu]

Ta version sur 40 threads tourne t elle sur GPU ?
Si c'est le cas, ça peut s'expliquer.
Les GPU étant basés sur l'architecture SIMD, ils sont très performants quand les tâches sont cohérentes, dans le sens où les tests ont globalement le même résultat, catastrophiques sinon. Notamment.
Ensuite, il faut de la quantité, parallelisable, pour bénéficier de leur puissance. Sinon et encore, leurs performances sont catastrophiques.



Un exemple extrême :
On veut paralléliser et exécuter sur GPU un réseau neuronal d'une couche. Pour cela, on subdivise la couche en tronçons, autant qu'il y a de threads.
Si la couche est très peuplée, on va avoir un gain énorme en performance.
Sinon, cette solution sera moins performante si le nombre d'unités est faible.
Concrètement si on simulait une couche d'un seul neurone par exemple, utiliser le CPU serait plus efficace que d'utiliser l'accélération matérielle (GPU ou GPGPU).



Pour finir :
-Favoriser la cohérence des tâches.(éviter les embranchements autant que possible)
-Paralleliser au maximum les tâches. Et favoriser les petites tâches.
-Limiter au maximum les transferts mémoire.( Entre mémoire graphique et mémoire CPU)

[Bubu]

Si tes 40 threads tournent par contre sur CPU....
Il faut autant de threads que de cœurs, ni plus ni moins. Le système peut te dire combien il y'en a.
Sinon, si il en a beaucoup, le CPU passera plus de temps à les synchroniser qu'à réellement les exécuter.

Il faut aussi limiter l'usage de la synchronisation (via mutexes, sémaphores, sections critiques) au strict minimum, et donc utiliser les design patterns appropriés.

[Benoit]

Est-ce qu'il y a une méthodologie "design pattern" en dynamique ?

En gros mon "réseau" à optimiser (Algo Gen) est très vide ("sparse" en anglais), ce qui me permet de le découper en dimensions ou plans relativement indépendants pour le traitement (ce qui n'empêche pas de devoir synchroniser pour contrôler l'évolution).

Par contre, je n'ai pas la connaissance a priori du nombre de plans/dimensions, encore moins à la fin quand le problème est grandement simplifié (après traitement des plans les plus indépendant).

Du coup, c'est à ce moment là que j'aimerai que l'OS se débrouille pour re-affecter les threads qui travaillent encore sur des cores vides.

J'espère que c'est compréhensible.

[Ixy]

Si tes 40 threads tournent par contre sur CPU....
Il faut autant de threads que de cœurs, ni plus ni moins. Le système peut te dire combien il y'en a.

Non souvent il peut y avoir plusieurs threads sur un coeur.

[Bubu]

Si tes 40 threads tournent par contre sur CPU....
Il faut autant de threads que de cœurs, ni plus ni moins. Le système peut te dire combien il y'en a.

Non souvent il peut y avoir plusieurs threads sur un coeur.

Oui et non .... avec les architectures multithreads oui, mais il y a quand même des conflits matériels sur les threads exécutés sur un même coeur, donc faut tester.
Je crois que les CPUs grand public sont tous maintenant multithreads , mais sur deux threads. Donc entre le nombre de cœurs et son double, mais pas plus. Il faut tester dans cet intervalle-là.

@Benoit : peut-être chercher du coté des thread pools ?
https://en.wikipedia.org/wiki/Thread_pool

[Benoit]

Je garde l'idée en tête, mais ça risque de me faire recoder tout le programme.

[Bubu]

Si tes 40 threads tournent par contre sur CPU....
Il faut autant de threads que de cœurs, ni plus ni moins. Le système peut te dire combien il y'en a.

Non souvent il peut y avoir plusieurs threads sur un coeur.

Bon je vais insister là dessus :
Les cœurs multithreads partagent le même matériel au niveau ALU, et mémoire cache notamment. D'accord, chaque thread à son propre registre d'instruction etc .... Mais imagine deux threads utilisant en même temps l'ALU ? Là il y a conflit matériel, donc aucun gain en performance, chaque thread, s’exécutant à tour de rôle. Aucun bénéfice en terme de performance.
Après oui, l'OS peut exécuter n'importe quel nombre de threads, mais les processeurs, non ! C'est à ce niveau de l'émulation ! Software ! C'est l'OS qui gère ça.

@Benoit : Les thread pools ne devraient pas poser problème : au lieu de créer un thread pour chaque tâche, tu crées les threads à l'avance, et les assignes à une certaine tâche quand tu as besoin. Cela évite l'opération très couteuse de les créer quand tu en as besoin. Tu crées ton thread pool, et tu assignes la tâche sur l'un dès que besoin. Normalement, tu n'as pas besoin de tout refaire ton code .... il suffit de créer un tableau de threads au démarrage de l'appli, et de leur assigner leur tâche quand tu en as besoin. En Java, c'est très simple en passant par l'objet Runnable. Sinon en C ou C++, tu leur balances un pointeur de fonction.

Un exemple d'implémentation en C++ (classe inline) pour Windows (de moi, donc pas forcément le meilleur) :

ThreadPool.h

(4 Kio) Téléchargé 36 fois

la dépendance #include "criticalsection.h" est inutile et peut (doit) être enlevée.
Et il manque une méthode pour attendre le résultat d'une tâche particulière .... ,
on ne peut qu'attendre la fin de toutes et obtenir un tableau des résultats ...
mais ce n'est pas trop dur de rajouter une telle méthode qui renvoie le résultat si besoin.

EDIT : si elle y est.
void * waitForTask(int taskIndex)

[Benoit]

Pour info, finalement je suis passé sur Cuda.
Les articles vendant du calcul sept mille fois plus rapide ont eu raison de ma patience.

Je ne désespère pas de faire l'acquisition d'un GPU avec plus de 192 coeurs (celle que j'ai pour l'instant, et ça n'a pas été drôle de l'installer sous Linux).

[Aden]

Question, je me demande si l'animation html5 est mieux ou a plus de possibilité que l'animation javascript ? Je connais que javascript mais je me demande si ça vaut la peine d'apprendre l'animation html5 ?

[Bubu]

Pour info, finalement je suis passé sur Cuda.
Les articles vendant du calcul sept mille fois plus rapide ont eu raison de ma patience.

Je ne désespère pas de faire l'acquisition d'un GPU avec plus de 192 coeurs (celle que j'ai pour l'instant, et ça n'a pas été drôle de l'installer sous Linux).

As tu envisagé OpenCl comme autre option ?
C'est pareil, sauf que c'est libre, et non restreint à la marque NVIDIA ? Compatible avec n'importe quel GPU ?

[Benoit]

J'ai comparé le nombre de lignes de code à faire pour les deux et les tutoriels (et la doc des cartes Radeon).

Pour l'instant je reste sur Cuda, au moins le temps de pouvoir appliquer directement les fragments de code sans avoir à faire de gymnastique de conversion.

[Bubu]

J'ai comparé le nombre de lignes de code à faire pour les deux et les tutoriels (et la doc des cartes Radeon).

Pour l'instant je reste sur Cuda, au moins le temps de pouvoir appliquer directement les fragments de code sans avoir à faire de gymnastique de conversion.

OK.
C'est juste que la portabilité de ton appli sera moins bonne, car ne fonctionnant qu'avec des GPU NVidia.
Mais si ce n'est pas un problème, tant mieux.

Aujourd'hui, les performances d'OpenCl sont équivalentes à celles de CUDA sur un GPU NVidia. Un temps ce n'était pas le cas, mais maintenant si.

Bon courage !

[Aden]

Question, je me demande si l'animation html5 est mieux ou a plus de possibilité que l'animation javascript ? Je connais que javascript mais je me demande si ça vaut la peine d'apprendre l'animation html5 ?

Quelqu'un peut répondre à mes questions svp ?

[Ixy]

Je connais pas l'animation avec html5.

Je sais que l'on peut faire plein de trucs marrants avec javascript, en étant statisticien il y a une bilblioth_que pour s'amuser avec les chiffres, il s'agit de D3js

[Bubu]

Question, je me demande si l'animation html5 est mieux ou a plus de possibilité que l'animation javascript ? Je connais que javascript mais je me demande si ça vaut la peine d'apprendre l'animation html5 ?

Quelqu'un peut répondre à mes questions svp ?

Je ne connais ni le JavaScript ni HTML5, désolé.