Objective C (Cocoa) et affinité des processeurs

[boulifb]

Bonjour,

J'aimerais savoir si quelqu'un parmi vous connait l'équivalent Cocoa des API Windows SetProcessAffinityMask et SetThreadAffinityMask qui permettent à un processus ou un thread de s'exécuter sur des processeurs ou coeurs définis par un masque. Je n'ai rien vu de tel dans la classe NSThread. Mais j'ai peut-être une mauvaise vue ou pas cherché là où il fallait

Si quelqu'un a suivit...

à bon entendeur,

Je vous salue.

Fred.

 

[ntx]

Et pourquoi ne laisses-tu pas l'OS s'en occuper ? Tu risques de faire plus de mal que de bien en le faisant par toi-même. :siffle:

 

[boulifb]

c'est pas trop la réponse que j'attendais
Laisser faire l'OS pour ce genre de tâche, n'est pas ce qu'il y a de plus malin à faire dans une application multi processus/thread. A quoi bon faire un thread ou un processus si le développeur n'a pas la main mise dessus quant au processeur sur lequel il s'exécutera?

Mais entrer dans ce genre de débat n'est pas le but du topic...
Rappel du sujet: gérer l'affinité des processeurs sous Cocoa.

Cordialement.

Fred.

 

[ntx]

Et comment sais-tu sur quel processeur/coeur il faut exécuter ton thread ? Comment sais-tu ce qu'est en train de faire l'OS sur les différents processeurs/coeurs ? Comment connais-tu les ressources disponibles ? C'est justement le rôle de l'Operating System de répartir les tâches entre ces ressources disponibles, mais si tu penses que tu peux le faire mieux que les développeurs d'Apple ... :zen: Et tant que tu y es, occupe toi aussi de la gestion de la mémoire, tu peux peut être aussi arranger les choses. :rateau:
Franchement, en dehors d'applications très spécifiques et très bas niveau (mais c'est peut être ton cas ? ) ou pour le fun, laisse faire l'OS. :zen:

PS : ce sont des opérations trop bas niveau pour être traitées au niveau de Cocoa. Regarde dans les API du noyau.

PS 2 : regarde si tu trouves ton bonheur ici ou là.

PS 3 : en fait ce serait plutôt là.

 

[boulifb]

Ok, merci.
Un de mes collègues m'a effectivement orienté vers l'API du noyau.

Ayant l'habitude de l'API Windows, ces instructions font parti de l'API utilisateur (qui doit surement transmettre les paramètres au noyau), ce n'est pas bien méchant en fait de savoir que fait un processeur et ce qu'il consomme. Mais sous Mac OS X c'est bien différent...

Je vais consulter de ce pas les documentations du noyau

Merci

 

[tatouille]

Ok, merci.
Un de mes collègues m'a effectivement orienté vers l'API du noyau.

Ayant l'habitude de l'API Windows, ces instructions font parti de l'API utilisateur (qui doit surement transmettre les paramètres au noyau), ce n'est pas bien méchant en fait de savoir que fait un processeur et ce qu'il consomme. Mais sous Mac OS X c'est bien différent...

Je vais consulter de ce pas les documentations du noyau

Merci

si tu veux une simple lecture de var sysctl

regarde de ce coter ci pour les threads

mach_port_t
mach_sys_syscall_thread_switch
mach_thread_info

 

[ntx]

ce n'est pas bien méchant en fait de savoir que fait un processeur et ce qu'il consomme.

Vu le nombre de processus système qui tournent en tâche de fond ça ne doit pas être si évident que cela d'avoir une information fiable dans la durée (au delà de l'instant). :siffle:

 

[boulifb]

C'est 10 ans de dev professionel sous Windows qui peuvent me permettre de savoir cela et que c'est pas difficile à faire

Quant à Mac OS X et Cocoa, je débute... Comme un bleu La couche unix, ça va bien un petit peu

 

[ntx]

Le problème est que Windows et Unix ne gèrent pas du tout les processus et les threads de la même manière, et pas à l'avantage de Windows.
Par contre je serais curieux de savoir comment tu t'y prendras pour déterminer le choix de processeur (ou du coeur) qui ne sera pas occupé par une tâche lancée par l'OS. Les systèmes modernes font quand même beaucoup de chose en douce, comme par exemple une petite indexation Spotlight ni vue ni connue ou une petite maintenance quotidienne.
Poste la solution quand tu l'auras.

 

[boulifb]

J'ai cru comprendre que la gestion des threads sous Unix a été "ajoutée" et ne tire pas parti de l'avantage des threads comme le fait Windows (rendons à César ce qui est à César - stop pas de polémique).

Sous Windows, l'unité d'ordonnancement est le thread et non le processus. Ce qui fait que lorsqu'un processus est créé, celui-ci est inherte et ne démarre pas tant qu'un premier thread n'est pas créé.

Si mes souvenirs sont bons, l'unité d'ordonnancement sous unix est le processus (lourd) et non le thread. Je vois mal comment un thread peut être ordonnancé sous unix au sens puriste du terme puisque le thread n'est pas son unité d'ordonnancement. Je ne vois qu'une émulation d'un processus "léger".

Enfin bon, je posterais la socluce dès que j'ai trouvé les instructions équivalente à SetProcessAffinityMask et SetThreadAffinityMask. Il doit être possible d'écrire une classe sous Cocoa qui permette cela.

Cordialement.

Fred.

 

[Anonyme]

Salut,

Je ne suis pas dev et je ne suis pas sûr de répondre à ta question mais voici un pdf en anglais qui explique tout pour les débutants dans xcode, peut-être que l'on parle des threads dedans...

Il y a aussi le centre Apple pour les devs (inscription gratuite) et j'y ai vu cet article.

 

[ntx]

J'ai cru comprendre que la gestion des threads sous Unix a été "ajoutée" et ne tire pas parti de l'avantage des threads comme le fait Windows (rendons à César ce qui est à César - stop pas de polémique).

C'est surtout que je trouve que mon Windows XP sur mon PC au bureau a souvent du mal à faire plusieurs choses à la fois alors que mon vieux Mac (Paix à son âme ) se débrouillait très bien avec plusieurs tâches en même temps (surf, décompression de zip, lecture de vidéo) avec une vingtaines d'applications ouvertes en arrière plan. (j'ai tendance à oublier de les fermer )

Sous Windows, l'unité d'ordonnancement est le thread et non le processus. Ce qui fait que lorsqu'un processus est créé, celui-ci est inherte et ne démarre pas tant qu'un premier thread n'est pas créé.

Et le main() ne créer pas ce premier thread ?

Si mes souvenirs sont bons, l'unité d'ordonnancement sous unix est le processus (lourd) et non le thread.

Exact

Je vois mal comment un thread peut être ordonnancé sous unix au sens puriste du terme puisque le thread n'est pas son unité d'ordonnancement. Je ne vois qu'une émulation d'un processus "léger".

Il faudrait aller se plonger dans le noyau BSD pour voir comment s'est foutu. :rateau:

 

[boulifb]

Si, le main() et le WinMain font en interne ce premier thread.
Sans m'avancer trop, car je ne joue pas souvent avec, CreateProcess nécessite un premier thread pour se lancer, sauf bien sur, si CreateProcess lance un exe.

Je ne suis pas trop chaud pour aller fouiller dans le code de BSD, même si celui-ci est dispo sur le site de la Pomme

C'est vrai que Windows au bout d'un moment se désagrège et ne fonctionne plus "très bien" (on va dire ça comme ça )

[Ajout]: pour ceux que ça intéresse (j'en doute) je peux donner quelques lectures intéressantes pour la culture générale sur Windows... Comme les théories, Windows sur le papier c'est joli, mais en pratique: c'est la cata (nous sommes d'accord).

 

[tatouille]

Si, le main() et le WinMain font en interne ce premier thread.
Sans m'avancer trop, car je ne joue pas souvent avec, CreateProcess nécessite un premier thread pour se lancer, sauf bien sur, si CreateProcess lance un exe.

Je ne suis pas trop chaud pour aller fouiller dans le code de BSD, même si celui-ci est dispo sur le site de la Pomme

C'est vrai que Windows au bout d'un moment se désagrège et ne fonctionne plus "très bien" (on va dire ça comme ça )

[Ajout]: pour ceux que ça intéresse (j'en doute) je peux donner quelques lectures intéressantes pour la culture générale sur Windows... Comme les théories, Windows sur le papier c'est joli, mais en pratique: c'est la cata (nous sommes d'accord).

je t'ai répondu comment obtenir ton info au lieu de blabla a la con ... enfin je crois tu as raté des parties sur ce qu'est un noyeau et un linker ecetera mais bon

pour accéder à ce que tu veux depuis le userspace prend tes petites mimines et fouille la ou je t'ai dit ca t'évitera de t'enfoncer ds des conneries

:zen: