Haskell et Multicore, qu'est-ce qui se passe vraiment

Question

J'essaie de comprendre ce qui se passe réellement lorsque vous voulez utiliser plus d'un noyau dans Haskell. This donne une bonne introduction, mais à mon humble avis n'est pas très critique et laisse de nombreuses questions ouvertes.

Lorsque j'utilise le combinateur par ou forkIO dans mon code et que je le compile avec l'indicateur -fileaded, que décide finalement si je reçois un thread OS ou non? Est-ce le compilateur ou l'OS?

Si j'utilise forkOS qui devrait toujours créer un thread OS, cela me libère-t-il des capacités du système d'exploitation sous-jacent?

Pour clarifier ma question: je suppose que dans un monde multicœur, le système d'exploitation sous-jacent/installé a des limitations en ce qui concerne le nombre de cœurs qu'il peut comprendre et utiliser. Est-ce que tout ce que je fais dans Haskell est tronqué par les capacités de l'OS? Ou, y a-t-il des moyens (quels sont-ils?) D'être meilleurs que le système d'exploitation dans un sens que si un hôte a 12 cœurs et les maîtres d'OS 8, puis-je pousser plus loin en écrivant une application intelligente dans Haskell? tout ce que je cours sur cet hôte avec cet OS soit limité à l'utilisation intelligente de 8 cœurs?

Answer 1

Le runtime Haskell détermine le nombre de threads OS à créer. L'OS décide comment mapper ces threads aux cœurs physiques et aux processeurs. Le compilateur n'a vraiment rien à voir avec ça, je pense ...

Il y a quelques calques ici. (Notez que le compilateur n'est pas dans ce schéma.)

 
+-----------------+ 
| User code | 
+-----------------+ 
     | 
     | forkIO creates 
     v 
+-----------------+ 
| Haskell threads | 
+-----------------+ 
     | 
     | Runtime library maps to 
     v 
+-----------------+ 
| OS Threads | 
+-----------------+ 
     | 
     | OS scheduler runs on 
     v 
+-----------------+ 
| Physical cores | 
+-----------------+ 

Le système d'exploitation ne sera jamais créer un thread OS pour vous, ce n'est pas fait son travail. Le système d'exploitation ne fait que ce que votre application et la bibliothèque d'exécution lui demandent de faire. Le système d'exploitation peut uniquement planifier l'exécution des threads de système d'exploitation existants sur des cœurs physiques.

La bibliothèque d'exécution choisit combien de threads OS sont créés ainsi que les parties de votre code qui s'exécutent sur quel thread. Vous avez un certain contrôle sur elle, mais une de ses fonctions est de mapper votre code aux threads du système d'exploitation. Comme vous pouvez le voir, si un OS est limité à l'utilisation de 8 cœurs, vous ne pouvez en aucun cas utiliser 12. Vous ne pouvez pas contourner les limitations du système d'exploitation. Cependant, les OS modernes supportent plus de cœurs que vous, donc ne vous inquiétez pas. (Si vous utilisez Windows XP, vous êtes coincé avec 2 cœurs. Mais il est stupide d'exécuter Windows XP sur une machine avec plus de 2 noyaux.)

Answer 2

1. pour obtenir quatre fils OS vous devez utiliser les option + RTS -N4 -RTS dans votre ligne de commande lorsque vous exécutez le programme. Pour obtenir un nombre différent de 4, il suffit de le remplacer. Par défaut (le runtime non-threaded) vous obtiendriez juste un thread de système d'exploitation, bien que vous puissiez exécuter beaucoup de threads d'E/S légers de GHC dedans. Avec -N4, le runtime lance 4 threads au démarrage du programme, puis les threads IO leur sont transférés. Oui, vous pouvez démarrer un thread OS explicitement avec forkOS. La raison pour laquelle vous voudrez peut-être faire cela est que si vous appelez une fonction C à travers le FFI, cela pourrait utiliser des E/S bloquantes et geler d'autres threads légers s'il s'exécutait dans les mêmes threads du système d'exploitation. Sinon, laissez le runtime gérer les threads du système d'exploitation.avez

   • http://www.haskell.org/haskellwiki/GHC/Concurrency