Discussion :

[Bash01]

Bonjour.

Dans le cadre d'un petit projet dans mon école, des amis à moi et moi-même avons du programmer un jeu dans lequel on peut soit faire du Humain vs Humain, Humain vs IA ou IA vs IA.

Le projet est totalement achevé aujourd'hui et marche bien. L'algorithme utilisé pour l'IA peut être soit le Min Max ou l'Alpha Beta (les deux ont été programmés). En IA vs IA, le jeu est très rapide quand on est en profondeur 2, mais quand on passe à 3, voire 4, la temps de réflexion entre chaque coup augmente considérablement.
J'ai pu remarquer que pendant ce temps de réflexion, un seul de coeur de mon processeur était utilisé.
J'aimerais donc savoir si quelqu'un connait un moyen de rentre l'application multicoeur (pour réduire sensiblement ce temps). Etant un débutant dans le domaine, j'aprécierais beaucoup si vous pouviez me lancer sur des pistes où c'est assez bien expliqué.

Merci.

[Médinoc]

Pour utiliser plusieurs cœurs simultanément, il faut que le programme exécute plusieurs threads.
Si tu veux faire le même calcul sur plusieurs threads, il faut alors que ledit calcul soit parallélisable. Typiquement, une boucle dont les itérations sont plus-ou-moins indépendantes l'est. Une boucle où chaque itération dépend de la précédente n'est PAS parallélisable.

Bref, la première chose à voir, c'est le niveau algorithmique. Si les algorithmes que tu emploies sont parallélisables, alors tu dois pouvoir en faire une implémentation sur plusieurs threads.

[Invité]

Tu peux utiliser OpenMP (inclus dans GCC, ici pous windows, omp.h)

[Bash01]

Merci beaucoup !

[Médinoc]

Les versions pro de Visual Studio 2005 et supérieur supportent également OpenMP.

[Invité]

Les versions pro de Visual Studio 2005 et supérieur supportent également OpenMP.

Exact. Attention cependant à la version (je chipote , c'est juste un détail, mais qui pourrait faire la différence). Le compilateur VS 2008 utilise OpenMP 2.0.

La version actuelle étant la 3.0.

[gangsoleil]

Bonjour,

Je séparerai deux choses : d'un cote la programmation parallèle, et de l'autre la programmation multithread.

Lorsque tu fais de la programmation multithread, tu ne t'occupes pas exactement de parallélisation : ton seul objectif doit être de séparer les différentes taches dans des threads, et éventuellement, si besoin, de gérer les points de synchronisation lorsque deux (ou plusieurs) threads ont besoin de se partager de l'information.
Le programmes multi-threads peuvent etre executes dans tous les environnements, et sont optimises pour les processeurs multi-threads (un processeur, un ou plusieurs cœurs, qui peuvent chacun exécuter en parallèle un certain nombre de threads).

De l'autre cote, dans la programmation parallèle, tu définis de manière explicite "telle fonction sera exécutée sur un premier cœur, et telle autre sur un second". Bien évidemment, cela fonctionne aussi avec un seul processeur qui ne dispose que d'un seul cœur.
Les programmes parallèles peuvent ensuite être optimises pour un certain nombre de cœurs et/ou processeurs, en fonction des besoins.
Idéalement, un programme parallèle tournera dans un environnement multi-processeur (et non pas multi-coeur).

Bien sur, il est possible de faire de la programmation parallèle multi-threadée. Il est aussi possible de se tirer une balle dans le pied :-)

[Médinoc]

Mais sur un système comme Windows, toute programmation parallèle reposera sur du multi-thread, la seule chose que le système accepte...

[souviron34]

Mais sur un système comme Windows, toute programmation parallèle reposera sur du multi-thread, la seule chose que le système accepte...

d'où l'opacité et l'incompréhension globale du problème "parallèlisme", "multi-thread", etc etc..

[Médinoc]

Tu sais, en l'occurence, "comme windows" incluait aussi les systèmes unixoïdes.

Mais peut-être que je me suis trompé, et que tu vas me dire qu'on peut faire des programmes marchant sur tous les linux, avec de la programmation parallèle ne faisant pas appel à plusieurs threads (ou processus) ?

[souviron34]

Tu sais, en l'occurence, "comme windows" incluait aussi les systèmes unixoïdes.

Mais peut-être que je me suis trompé, et que tu vas me dire qu'on peut faire des programmes marchant sur tous les linux, avec de la programmation parallèle ne faisant pas appel à plusieurs threads (ou processus) ?

bien sûr...

MPI est fait pour ça

Et sur d'autres systèmes unixoides spécialisés (Silicon Graphics pour ne pas le nommer, en graphisme intensif, dès 1989, de même que InterGraph dès 1987), le "multi-coeur", ou plutôt "multi-CPU" était prévu, avec des variables d'environnement N_CPUS, et soit une parallèlisation manuelle ou automatique qui transformait toutes les boucles en "for ( i = 0 ; i < N_CPUS , ; i+)"..




Une bonne discussion était ici-même:

multi-threading et multi-core

[Médinoc]

Tout ce qu'on m'a dit sur MPI en cours de parallélisme, c'est que ça servait pour des calculs parallèles multi-processus. En fait, on ne nous a pas montré grand-chose d'autres que des fonctions d'IPC plus élaborées que la moyenne (comme une réduction sur plusieurs processus)...

[souviron34]

regarde les sources du Net sur MPI, ou sur Grid-Computing...

C'est de très très très loin le plus utilisé pour tout ce qui est parallèlisme industriel, que ce soit multi-machines, multi-coeurs, etc etc...

Tout simplement pour la raison ci-dessus : le même programme parallélisé peut tourner et sur plusieurs machines et sur plusieurs coeurs..

Les threads étant locaux, ça ne marche que de manière limitée..

Et de plus, pour l'écrasante majorité des vrais programmes/problèmes de parallèlisme, c'est la lourdeur du calcul qui est en cause, pas d'autres tâches..

(d'où la référence au Grid-Computing)

C'est donc par exemple calculer N blocs de multiplication de matrice en //, ou bien faire 2 calculs de propagation matricielle en //, etc etc..

C'est pour ça que, dans la discussion que j'avais pointée plus haut, il y avait une vraie distinction entre les 2 approches..

PS: je te répondrais qu MP plus tard dans la semaine