Depuis Bull a pondu les CPU sets, qui permet de dire exactement sur quel processeur virtuel (thread, coeur, processeur) tu veux « visser » un processus ou un thread (la différence entre les deux étant relativement minime, vu que dans tous les cas on appelle clone()).
Je m'en sers en ce moment pour faire tout un tas de tests et autres benchmarks (notamment, évaluer l'impact des caches partagés par rapport à du SMP classique), et je pense que pour une application mono-utilisateur, on finira par devoir un minimum s'y intéresser, ne serait-ce que pour certaines tâches critiques. C'est un peu ce que fait Mac OS quand de l'OpenGL est exécuté : plutôt que d'avoir un processus affecté à un coeur par le système, et le runtime OpenGL qui s'exécute sur ce même coeur, on le fait se lancer sur l'autre coeur, pour alléger la charge. OpenGL n'en est pas rendu thread-safe pour autant, mais on a au moins découplé le côté « rendu » du côté « traitement ».
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 4.
Je m'en sers en ce moment pour faire tout un tas de tests et autres benchmarks (notamment, évaluer l'impact des caches partagés par rapport à du SMP classique), et je pense que pour une application mono-utilisateur, on finira par devoir un minimum s'y intéresser, ne serait-ce que pour certaines tâches critiques. C'est un peu ce que fait Mac OS quand de l'OpenGL est exécuté : plutôt que d'avoir un processus affecté à un coeur par le système, et le runtime OpenGL qui s'exécute sur ce même coeur, on le fait se lancer sur l'autre coeur, pour alléger la charge. OpenGL n'en est pas rendu thread-safe pour autant, mais on a au moins découplé le côté « rendu » du côté « traitement ».