Bonjour,

J'aimerai réaliser une simulation du jeu de la vie pouvant tirer partie d'un processeur à 4 coeurs de la manière suivante.

On imagine une matrice 4x4 ou chaque carré se verra assigné un jeu de la vie, ce que je souhaite c'est dédié de façon "stricte" un core pour chaque carré.

Ainsi on aura 4 instances du jeu de la vie complètement indépendante.

Ce que je souhaite savoir indépendamment de l'implémentation du jeu de la vie, c'est comment confier une tâche spécifiquement à un core et pas aux autres. Et ceci dans le langage Java.

(Vous pouvez très bien me donner un exemple avec des opérations simples utilisant ce principe)

Merci à vous.

Bonjour,

Ainsi on aura 4 instances du jeu de la vie complètement indépendante. non, elles ne sont pas indépendantes. Mais heureusement pour toi, la dépendance reste suffisamment limitée pour que tu puisses t'en sortir.

« c'est comment confier une tâche spécifiquement à un core et pas aux autres. » basiquement, tu ne peux pas. Et quand même tu le ferais, ton système s'écroulerait (il a des milliers de choses à faire chaque second, et sans core pour les faire, BOOM).

La seule chose que tu puisses viser, c'est découper ton problème en quatre comme tu le décris et lancer les 4 instances dans 4 threads différents (qui vont en temps normal bien se répartir sur les 4 core grâce à l'ordonnanceur de ton système d'exploitation).

Bonne chance.

Merci de ta réponse.

On ne peut donc pas assigner spécifiquement du travail à des cores spécifiquement choisi? On dépend toujours de l'ordonnanceur?

Ne puis-je pas dire ceci?

A core#0 instance du jeu de la vie avec x,y cells
A core#1 instance du jeu de la vie avec x',y' cells

etc?

Non, tu ne peux pas. De toute façon, si tu le faisais, tu ferais à coup sûr moins bien que l'ordonnanceur de ton OS qui :
1/ a été codé par des professionnels,
2/ a été intensivement testé,
3/ a accès à des tas d'informations utiles (que toi tu ne peux pas avoir) pour prendre de meilleures décisions.

Ok ça marche merci

Heu, je ne sais pas en java. Mais tu peux attacher un thread systeme a un thread hardware particulier. Ca s'appelle du thread pinning et ca se fait en c avec pthread_set_sched_affinity. C'est communement utilise en calcul haute perf pour tirrer partie de localite memoie. Apres I'll faut savoir ce que l'on sinon en effet les performance s'ecroulent pour les raisons invoquer par chris.

Je ne suis pas bien sur d'avoir compris ce que op cherche a faire. La programmation multicoeur sert uniquement a acceller un calcul. Est ce que le calcul que tu fias est lent pour commencer? I'll y a un seuil en dessous duquel paralleliser n'est pas possible

Godrik c'est en aucun cas pour accélérer un calcul (je sais bien qu'on // justement pour cela), pour ma part je voulais juste savoir si il était possible de "cibler" un coeur d'une façon spécifique.

http://en.wikipedia.org/wiki/Processor_affinity

godrik: je pense que l'OP cherche à faire ça par simple but pédagogique.

Sinon, pthread_set_sched_affinity (enfin, c'est j'ai que pthread_set_affinitynp et c'est linux only) ça n'offre aucune garantie de réussite, si ?

-c'est

Je ne connais pas pthread en détail mais j'aurai pensé que ces fonctions étaient plutôt destinées à élever la priorité. Je vois mal le développeur pouvoir décider clairement de l'utilisation physique du processeur sachant que l'OS a ses propres choses à faire et que ça aurait des implications de sécurité.

Mais pour répondre du point de vue java, la JVM utilise effectivement des vrais threads (c'est pas le cas de toutes les technos) et le seul contrôle que tu peux avoir c'est la priorité qui va sauf erreur de 1 à 10.

C'est fonction permettent de donnee un mask de thread physique ou un thread systeme peut s'executer. Pour une application haute performance, le systeme fait des choix d'execution assez con. migrer un thread d'un coeur a un autre ou d'un processeur a un autre est toujours catastrophique. Essayer d'executer n simple benchmark openmp avec ou sans affinite de thread, vous verrez certainement une difference de 15% de runtime. Regardez dans [1] l'importance de l'allocation des thread a des coeurs sur un probleme de coloration de graph. La majorite du papier concerne une execution sur machine a memoire distribue, mais la figure 4a concerne une execution sur une seule machine. On retrouve les meme effets sur a peu pres toutes les applications de calcul parallele (algo de graph, algebre lineaire dense et creuse, imagerie...)

Le systeme ne connait pas la logique applicative. Du fait, il n'est pas possible pour lui de scheduler des threads intelligement. Parcontre, si on fixe un thread par core, alors le developpeur peut allouer les taches de calcul intelligement. Deplus, il est important pour le scheduler de tache de l'applicatoin que les threads ne bougent pas, ca permet de tirer partie d'une allocation precedente et de s'assurer que les caches sont deja plein. Les donnees du scheduler de tache sont aussi toujours en cache, migrer un thread hors du niveau de cache qui va bien est alors une catastrophe. De facon sur, le scheduler d'openmp fonctionne comme ca. Les executions parallele base sur les techniques de workstealing ont besoin de thread fixer sur un core (cilk, kaapi, xkaapi, Intel cilk plus). Certains scheduler reutilisent des informations de scheduling passe pour faire leur decision future (affinity_scheduler de intel TBB).

Savoir ou sont les threads est egalement imperatif pour faire de l'allocation de memoire pour les machines qui ont des effets NUMA. Pour rappel, une machine a des effets NUMA quand certaine partie de la memoire, sont plus proche de certain coeur que d'autre. Par exemple, la plupart des machines multiprocesseurs sont comme ca. La plupart des noyaux ont une politiuqe d'allocation de la memoire dites first-touch, c'est a dire que la memoire physique est alloue sur le banc memoire le plus proche du coeur qui accede cette memoie (page) le premier. Si tu laisse le systeme faie ce qu'il veut, tu va te retrouver avec de la memoire distribue dans tous les banc memoire et les performances vont tomber. Sur la plupart des systeme que j'ai regarde, les access memoire sur un noeud numa different sont 3 fois plus lent (bandwidth et latency) que sur le noeud numa local.

[1] http://bmi.osu.edu/~esaule/public-website/paper/pco12-SSC.pdf

interdependance, oui c'est possible en C, j'imagine que ca doit l'etre aussi en java. Utiliser plusieurs coeur n'est pas completement facil et ca sert toujours a accelerer un calcul. Cependant, ce n'est souvent pas la technique la meilleur, paralleliser est souvent la derniere chose a faire pour accelerer un calcul. Parceque ce que tu gagnes a paralleliser depend de ton architecture.

Typiquement ce que tu gagnes a utiliser du parallelisme est plus d'instruction processeurs. Si ton application est borne par les instructions (instruction bound), alors paralleliser peut etre utile. Cependant, ce n'est pas l'unique solutoin, reecrire le code pour utiliser moins d'instruction est souvent la bonne approche. La vectorization du code est aussi tres efficace a ce niveau.

Si ton application est borne par la memoire alors le probleme est plus complique. Paralleliser peut apporter un gain de performance pour plusierus raisons. 1/ parceque quand tu as plusieurs thread tu overlap communication et calcul. Cet effet apparaissait deja sur les architectures non parallele ou sur les architecture multi thread (hyperthreading). 2/ avoir plus de core permet d'emmetre plus d'instruction d'access memoire en meme temps et permet de s'assurer que le bus memoire reste saturer. 3/ avoir plus de core veut aussi dire plus de registre et plus de cache. Donc si tu regle ton application pour maximiser la localite des access memoire, tu aura un gain net a utiliser plus de processeurs (parceque tu as virtuellement plus de cache).
Cependant si ton application est borne par la memoire, c'est souvent plus efficace d'optimiser les access memoire en s'assurant qu'ils ont la plus grande localite.

Finalement, la programmation parallele, ce n'est jamais simple et il y a plein de situation bizarre qui flingue les performance. Ma politique est: obtient le code sequentiel le plus rapide que tu peut. Et si tu n'as toujours pas assez de performance, envisage le calcul parallele.

Merci à vous!

pour les anglophones:

http://support.amd.com/us/Processor_TechDocs/47414_15h_sw_opt_guide.pdf

chapitre 11