Bonjour,
Je me demandais si il était possible grace à l'aide de la programmation système d'avoir la main sur le processeur/coeur qui execute le code d'un thread ou d'un processur précis (pour, par exemple vouloir paralelliser du calcul)
 
 
 
Merci,
Grégoire

en general tu t'en moques car la partie parallélisation passe rarement par ça. SOus posix pthread je pense que c'ets pas possible (ou du moins compliqué à bidouiller via affinity) et sous windaube aucune idée.
 
Qu'est-ce que tu cherches à paralléliser ?

Sous windows c'est pareil, il faut bidouiller l'affinity, c'est bien dégueux et je suis même pas sûr que ça soit gérable à une résolution inférieure au processus

Rien de précis mais je travaille sur un protocole pour paralelliser un calcul via le réseau et je trouverais bête de ne pas exploiter tous les coeurs de chaque machine à cette échelle là.
 
J'ai remarqué qu'en lançant plusieurs processeur l'ordonancement se débrouillait déja bien, mais si je lance N threads (ou N est le nombre de coeurs) et que deux se lancent sur le même je perds tout interêt....
 
Et puis même, c'est quand même bête de ne pas pouvoir exploiter les coeurs à notre guise en tant que développeurs
 
Je continue à chercher!

bah c'est pas à l'OS de le faire :E
en gros, il faut que ton binaire pour une machine N coeurs utilise explicitement les k coeurs en interne ...
 
Y a pas de magie en parallélisme

Ben si c'est bien à l'OS (ou au scheduler de l'OS en tout cas) de mapper les threads/process sur des cores le plus efficacement possible, c'est à ça qu'il sert quand même, un peu

oui mais c'est pas à lui de paralléliser le dedans des applis je voulais dire :E
 
Après si les exe sont indépendant, oui faut y aller à coup de nice ou de jesaisplusquoi au niveau système mais ca reste moche.

sous windows, de toute façon, l'affinité ne garantit aucunement que ton thread va tourner sur le processeur (logique) que tu lui spécifies, ca te dit juste que le scheduler tentera de le mettre plutôt sur celui-ci
 
Et si, ca se sélectionne au niveau du thread à coup de setthreadaffinity (à coup de masque d'affinité pour setter plusieurs processeurs) ou à coup de SetThreadIdealProcessor (et là, tu ne précises que le numéro du processeur préféré)

Mais tu fais ça comment ?
Je m'explique : en toute logique t'as un processus père et n processus fils, répartis sur le réseau. En ce cas il suffit de lancer autant de fils qu'il y a de CPUs disponibles sur les machines cibles, comme ça l'OS se charge de la répartition des processus sur les coeurs disponibles. Et le père n'a qu'à répartir les taches sur les fistons déclarés sans chercher plus à comprendre, non ?
En tout cas c'est comme ça que c'est fait chez nous.

Bien sûr, c'est ce que je voulais faire et surement ce que je vais faire, mais lancer plusieurs processus ne garantit en aucun cas que chaque processus aura son propre coeur/processeur

Mais ça tu t'en contrefous, le scheduler de l'OS est censé se démerder pour que les ressources soient utilisées de la meilleure manière possible, oui il peut mapper 2 de tes threads sur le même core si un autre core est bouffé par une app qui prend des ressources, mais qu'est-ce que tu en as à faire?

 
Exactement, c'est complètement pas ton problème

L'erreur c'est aussi de penser qu'intuitivement on va faire mieux que l'ordonnanceur.
Je pense que le seul moment où ça peut se justifier (setaffinity, etc) c'est quand les threads ont des priorités différentes, on sait que jusqu'à des version récentes de linux ça pouvait donner des trucs bizarres.

et comment peut-on voir si notre Appli est  utilise tel ou tel coeur ??

ps :€

comment   ?