Discussion :

[aeropostale]

Voilà, voilà


ma question est assez simple:
existe-t-il une façon simple de faire du multithreading avec caml light? A la rigueur, écrire le programme en ocaml ne me dérangerais pas.
(Il s'agit d'un simple solveur de hitori, jeux japonais type sudoku ou je pense pouvoir uitiliser dans une certaine mesure la puissance de deux processeurs).


Merci d'avance pour votre aide.

[gasche]

Si tu as besoin de performances, le simple fait de passer de Caml light à Objective caml te donnera un avantage bien plus important que l'utilisation de tes deux cores.

Par ailleurs, si tu es certain que tes algorithmes sont optimaux, tu peux passer par une phase de profiling (avec gprof), qui peut être elle aussi très bénéfique (tu peux t'attendre à une multiplication par 10 des performances après un profiling un peu soigneux sur un code pas forcément pensé pour la vitesse au départ).

Enfin, tu pourras t'intéresser au parallèlisme. Le plus simple à priori est de faire un fork() de ton programme en deux processus, et de les faire communiquer par un pipe/socket local.

[InOCamlWeTrust]

Pas sûr que le thread OCaml permettent d'utiliser les deux processeurs en même temps.

Si on en croit le manuel de référence, et Xavier Leroy y connaît quelque chose en termes de thread...

The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes.

Voilà, pour ceux qui avaient un doute, il est levé, du moins pour la version 3.10 de OCaml.

[alex_pi]

http://osp.janestcapital.com/wordpress/, deuxième projet. Si c'était déjà multi-thread, ils ne bosseraient pas dessus :-)

[gasche]

On peut utiliser fork() pour répartir les calculs sur plusieurs cores, et la bibliothèque coThreads pour programmer comme avec le module Threads tout en utilisant plusieurs processus->processeurs/cores.

[LLB]

Vu que tu fais du Caml light, tu devrais pouvoir passer à F# aussi simplement que passer à OCaml.


plus de détails ici : http://www.developpez.net/forums/sho...d.php?t=554164

[LLB]

Pas sûr que le thread OCaml permettent d'utiliser les deux processeurs en même temps.

Juste pour compléter : http://caml.inria.fr/pub/ml-archives...38fb15.en.html

Extraits :

Why was Concurrent Caml Light abandoned? Too complex; too hard to debug (despite the existence of a machine-checked proof of correctness);
[...]
In summary: there is no SMP support in OCaml, and it is very very unlikely that there will ever be.

Ça date de 2002.

[InOCamlWeTrust]

A mon avis, ce genre de questions ne devraient aucunement intéresser le programmeur final, et ce pour plusieurs raisons.

1- Pourquoi s'intéresser au nombre de processeurs ? C'est une question de hardware, et ici, on fait du soft écrit en fonctionnel... donc on est très loin de ce genre de considérations ! Si on commence par se préoccuper de ce genre de choses, alors pourquoi pas aussi s'intéresser, dans le code, de la TLB (très important), de la localisation des données (super important, mais n'a aucun sens en fonctionnel), ou encore du type de clavier qu'utilise le mec qui fait tourner le programme écrit ?

2- Même si ce genre de choses existaient (ou existent), les codes seraient tout pourris et perrimés le jour même. X écrit un programme pour son DualCore (2 CPU). Y, ami de X, fait tourner le programme de X sur sa grosse station de travail UltraSparc VI avec 32 CPU (eh oui... il a investi dans un joli bijoux). Conclusion : le code de X est foutu, car il était optimisé pour 2 CPU x86, mais pas pour 32 CPU SPARC.

3- C'est l'affaire des OS, pas des programmeurs. Beaucoup de progrès ont été effectués du côté soft, mais force est de constater que les OS, UNIX et Linux compris, ont peu évolué. Les modifications apportées concernent rarement le fond, le coeur du système, et consistent souvent en de nouvelles intégrations de nouveaux trucs dont tout le monde s'en fout royalement. Heureusement, les gens commencent à s'en rendre compte.

[LLB]

1- Pourquoi s'intéresser au nombre de processeurs ? C'est une question de hardware, et ici, on fait du soft écrit en fonctionnel...

Dans l'absolu, oui.

En pratique, les compilateurs usuels ne savent pas parralléliser automatiquement le code. Si on souhaite qu'une application utilise efficacement les processeurs disponibles, il faut lui dire.

Pour le reste, tu as raison : qu'il y ait 2 ou 32 processeurs disponibles, le code devrait être le même (la solution du fork n'est donc pas bonne). C'est pour cela que j'apprécie beaucoup ce qui est proposé pour .Net (j'imagine qu'il y a des équivalents pour les autres langages/plateformes) : on donne une liste de tâches à effectuer en parrallèle et tout le travail est distribué équitablement, en fonction du nombre de processeurs.

[gasche]

Pour le reste, tu as raison : qu'il y ait 2 ou 32 processeurs disponibles, le code devrait être le même (la solution du fork n'est donc pas bonne).

Sauf qu'en pratique ce n'est pas vrai, parce qu'entre 2 et 32 processeurs, les conditions d'utilisation changent trop. À 32 processeurs (ou peut-être 64 ou 128), tu n'auras plus une mémoire partagée à temps d'accès égal depuis chaque processeur, et les modèles de programmation à mémoire partagée deviennent donc inadaptés. En particulier, le machin super chouette trop bien que fait .NET devient inutile, et dépassé.

[InOCamlWeTrust]

Si tu pouvais expliquer, ce serait cool... car là, je comprends pas trop ce que tu veux dire.

[gasche]

Et bien la concurrence à base de mémoire partagée (c'est à dire les threads) repose sur l'hypothèse suivante : tous les threads peuvent accéder aussi facilement qu'ils veulent à toute la mémoire.

Dans un contexte d'hyperthreading ou même de multi-core (2, 4 coeurs, quelque chose de gentillet), c'est vrai : les caches L2 sont partagés (dans le cas intel) ou en tout cas c'est très facile d'avoir accès à la mémoire de tout le monde. Quand tu multiplies les cores, ça ne marche plus : si tu as 64 cores, tu ne peux plus forcément faire un cache commun, et c'est pas trop praticable de laisser n'importe quel core accéder à la mémoire traitée par n'importe quel autre (puisque les canaux de communication augmentent quadratiquement par rapport au nombre de core dans ce cas de figure).

Tu te retrouves donc à restreindre les méthodes communication, avec tout un tas de méthodes compliquées que je ne connais pas, et en essayant du mieux possible, mais tu te retrouves quand même dans une situation où l'accès à la mémoire n'est plus homogène : les cores vont avoir des zones de "mémoire rapide" où ils peuvent accéder facilement (par exemple leur cache et celui de leurs "voisins directs"), et des zones où il faut envoyer un machin, attendre que la bureaucratie interne fasse son travail, etc.

L'hypothèse de la concurrence à mémoire partagée ne tient donc plus : tu es dans une situation où deux processus qui ne tournent pas sur le même core ne peuvent plus dire "on partage tout, on est de vrais amis" parce que tu aurais des temps de latence trop gros dans certains cas. Du coup, tu dois adopter des stratégies différentes qui sont plus ou moins de l'ordre de l'envoi de message au lieu du partage total de la mémoire (ou des modèles hybrides ou je ne sais quoi). Mais dans tous les cas, tu ne peux plus dire "j'ai plein de threads et je les lance sur n'importe quel core comme si de rien n'était", parce que ce n'est plus vrai.

Et du coup le superbe GC concurrent, intelligent et à gros zizi, il n'est plus aussi utile. Sachant que c'est un bout de logiciel très complexe, et qui a un surcoût en performances conséquent par rapport aux GC non parallèles comme celui de OCaml (dans les contexte où le parallèlisme n'est pas exploité, évidemment), et bien c'est très dommage. Surtout que dans une situation de message-passing, où la mémoire est complètement séparée, il se trouve que le GC OCaml fait aussi bien que le GC .NET, et même mieux : au lieu d'avoir un GC concurrent qui essaie de tout gérer à la fois et qui est compliqué, on a un GC OCaml par processus, mais chaque GC est plus léger. Ça marche très bien et c'est JHarrop qui le dit lui-même sur cet autre thread. Quoi, il dit des choses différentes, voire légèrement contradictoires (mais pas complètement, puisque quand il parle du GC .NET il évoque des situations théoriques à mémoire partagée, et quand il parle de caml il parle d'une situation concrète où le passage de messages suffit), d'un thread à l'autre ?

[gorgonite]

et pourquoi personne ne parle de MPI ?

[InOCamlWeTrust]

Dans un contexte d'hyperthreading ou même de multi-core (2, 4 coeurs, quelque chose de gentillet), c'est vrai : les caches L2 sont partagés (dans le cas intel) ou en tout cas c'est très facile d'avoir accès à la mémoire de tout le monde.

Comme tu le dis : c'est vrai pour Intel, mais pas pour AMD... Cette "feature" du Xeon est propre à Intel, car AMD, lui, a opté pour la solution intelligente de ne pas partager le cache... et c'est ce qu'il faut faire car, sinon, on se retrouve trop souvent dans le cas où un CPU est bloqué le temps que l'autre accède à la mémoire et la modifie.

Quand tu multiplies les cores, ça ne marche plus : si tu as 64 cores, tu ne peux plus forcément faire un cache commun

Faut pas faire des caches communs ! C'est une solution de débiles mentaux proposée par Intel ! Pourquoi avoir plusieurs CPU si c'est pour qu'ils passent la plus grande partie de leur temps à se tourner les pouces ?

Tu te retrouves donc à restreindre les méthodes communication, avec tout un tas de méthodes compliquées que je ne connais pas, et en essayant du mieux possible, mais tu te retrouves quand même dans une situation où l'accès à la mémoire n'est plus homogène : les cores vont avoir des zones de "mémoire rapide" où ils peuvent accéder facilement (par exemple leur cache et celui de leurs "voisins directs"), et des zones où il faut envoyer un machin, attendre que la bureaucratie interne fasse son travail, etc.

Oui, mais en pratique les zones d'accès rapides pour chaque CPU correspondent aux zones auxquelles ils accèdent fréquemment : donc l'hétérogénéité n'est pas un problème en soi, et les méthodes de communication sont vraissemblablement ou internes au CPU (donc tout le monde s'en fout et personne ne s'y intéresse) ou, au pire, seulement guidées par des fonctions très très bas niveau de l'OS... donc à la fin, tout le monde s'en fout encore !

P.S. : c'est cru, mais il n'y a pas de méchanceté !

L'hypothèse de la concurrence à mémoire partagée ne tient donc plus : tu es dans une situation où deux processus qui ne tournent pas sur le même core ne peuvent plus dire "on partage tout, on est de vrais amis" parce que tu aurais des temps de latence trop gros dans certains cas.

Hmmmmmmmm... pas la peine de TOUT partager : il suffit de partager ce qu'il est nécessaire de partager. C'est ça la force de tout séparer (cache et CPU) : chaque CPU possède son cache à lui dans lequel il charge ce dont il a besoin. Concernant les temps de latence, ils sont plutôt à redouter dans les design avec partage de cache et non l'inverse.

Et du coup le superbe GC concurrent, intelligent et à gros zizi, il n'est plus aussi utile. Sachant que c'est un bout de logiciel très complexe, et qui a un surcoût en performances conséquent par rapport aux GC non parallèles comme celui de OCaml (dans les contexte où le parallèlisme n'est pas exploité, évidemment), et bien c'est très dommage. Surtout que dans une situation de message-passing, où la mémoire est complètement séparée, il se trouve que le GC OCaml fait aussi bien que le GC .NET, et même mieux : au lieu d'avoir un GC concurrent qui essaie de tout gérer à la fois et qui est compliqué, on a un GC OCaml par processus, mais chaque GC est plus léger. Ça marche très bien et c'est JHarrop qui le dit lui-même sur cet autre thread. Quoi, il dit des choses différentes, voire légèrement contradictoires (mais pas complètement, puisque quand il parle du GC .NET il évoque des situations théoriques à mémoire partagée, et quand il parle de caml il parle d'une situation concrète où le passage de messages suffit), d'un thread à l'autre ?

Oui : mieux vaut faire un truc très simple mais redoutablement efficace comme le GC de OCaml qu'un gros caca qui fait tout et surtout n'importe quoi.