Par "Concurency" Je veux dire des processus légers comme les acteurs d'Erlang et le GC simultané visant à faire fonctionner un tel processus.
Ce serait très cool si l'INRIA s'est débarrasser de ces inconvénients de la mise en œuvre actuelle de l'OCAML pour rendre OCAML plus préparé pour l'avenir multicœurs.
P.s. F # n'est pas ce que je cherche.
4 Réponses :
Non < / p>
Je ne peux pas être plus concis sans reproduire son explication. Il parle pour lui-même. Oui, cela vient de 2002, mais je ne l'ai pas entendu parler de la question et du texte, il ne semble pas probable du tout qu'il redescendrait de ces objectifs.
Pour les développements en cours sur la programmation fonctionnelle simultanée, éventuellement des solutions MPI ( avec des liaisons OCAML ) pourrait être une solution à votre problème. Évidemment, ce n'est pas un parallélisme de mémoire partagée. Il y a aussi simultanément ML .
Je ne suis pas prêt à creuser dans les archives tout à l'heure, mais je suis sûr qu'il y a eu des discussions plus récentes où des sentiments similaires ont été exprimés. L'INRIA est axée sur le langage OCAML soutenu, comme l'est, ce qui ne pousse pas de nouvelles nouvelles fonctionnalités telles que LWP ou une heure d'exécution simultanée. N'est-ce pas en partie le point de HLVM de Jon Harrop?
OCAML4Multicore est disponible (avec des limitations), voir: Algo-Prog.info/ocmc/web - a>
Vaut la peine de noter: Ce que M. Leroy a livré cette conférence à la liste OCAML en 2002, c'était le cas que les machines SMP n'étaient pas aussi communes qu'aujourd'hui. Néanmoins, il reste à voir si l'ajout d'un parallélisme partagé-mémoire à l'exécution de l'OCAML est une victoire sur l'approche la plus traditionnelle de l'optimisation des systèmes SMP: Fork / Exec et Communication interprocédent. On dirait que l'Inria n'a pas encore apporté des annonces que son esprit collectif a changé.
@james Woodyatt: "Approche traditionnelle pour optimiser les systèmes SMP: Fork / Exec et communication interprocessée". De telles approches ne fonctionnent que bien sur les systèmes distribués et, en particulier, ne fonctionnent pas bien sur les multicores en raison du bus de mémoire partagée et des caches hiérarchiques.
@JONHARRROP: Pourquoi l'IPC ne fonctionne-t-il pas bien dans cette situation? Vous ne pouvez toujours pas faire de mémoire partagée IPC avec OCAML? Ou ne pourriez-vous pas au moins le faire avec des liaisons à une bibliothèque C pour faire la configuration?
@Josephgarvin: Il suffit de pousser le problème. IPC signifie généralement copier au lieu de la mémoire partagée, ce qui est mauvais pour la multicore car la copie signifie beaucoup de cache inutiles qui finissent par la soumission de la mémoire partagée. Vous pouvez partager la mémoire à l'aide de la carte IPC, mais il est hors de portée du GC afin que vous fassiez une gestion de la mémoire manuelle (pas vraiment OCAML) ou vous l'utilisez simplement comme tampon pour copier des données autour (qui tue toujours la performance multicœur). La seule solution qui fonctionne sur un multicœur est d'exploiter le support matériel à la mémoire partagée et, en particulier, cela signifie la mutation de la place.
@JONHARRROP: Quand un noyau écrit à la mémoire, puis un autre noyau accède à cette mémoire, il obtiendra paresseusement cette valeur sur le bus (en supposant qu'il utilise Mesi, c'est peut-être une hypothèse obsolète?). C'est la copie coûteuse, non? Cela va se passer, que vous partagiez réellement l'objet ou que vous l'utilisiez comme tampon - si vous y accédez, vous déclenchez le trafic sur le bus. Donc, je ne suis pas sûr de voir le côté bas de l'utiliser comme tampon, au moins de concurrence sage (encore plus lent dans l'ensemble, car vous ferez une copie intra-processeuse supplémentaire pour l'amener dans l'espace d'adressage du processus).
@Joseph: Considérez le cas du partage d'un grand définir utilisé par deux noyaux avec un cache partagé. Avec un tas partagé, vous avez une copie de l'ensemble dans le cache partagé et les deux cœurs en lisent. Avec le passage de message, vous créez un duplicata de l'arborescence entière qui utilise deux fois plus de mémoire et les deux copies sont en concurrence pour espace dans le cache partagé.
@Jonharrop: Ah, je suis plus utilisé pour penser à des flux rapides de beaucoup de minuscules messages qui sont rapidement jetés. Mais la plupart des CPU de bureau / serveur ont aujourd'hui des caches locaux et partagés de la CPU, de sorte que les copies ne devraient pas rivaliser pour l'espace de cache partagé, si elles? Sur ces processeurs, je ne suis pas vraiment sûr de ce que le protocole est de décider quand déplacer des données entre le cache partagé et le cache local.
@Josephgarvin: Si vos messages transportent une quantité importante de données, le passage du message naïf sera en profondeur de copier des données lorsqu'elle pourrait être adoptée par référence. Du point de vue du matériel, ces copies sont différentes données afin de concurrencer le même espace dans un cache partagé. Cependant, si vous passez de nombreux messages minuscules, il n'y a pas de différence comme vous le dites. Je crois que les caches locales se répliquent juste une partie de ce qui se trouve dans les caches partagées.
Malheureusement, le lien d'archive de liste est maintenant cassé.
Il y a J & OCAML , qui est ...
Objectif CAML Plus (&) Le Rejoignez Calculus , c'est-à-dire OCAML étendu pour une programmation concomitante et distribuée.
Mais même avec Jocaml, vous devez expliquer explicitement la fourchette si vous souhaitez utiliser plusieurs cœurs.
Il semble que Jane Street a financé un projet d'ajout de GC simultané à OCAML
Cela a culminé dans OCAML4Multicore mais ce n'est pas très utile car l'allocation dommageait sérieusement l'évolutivité et l'allocation est pratiquement inévitable dans OCAML en raison du manque de types de valeur.
Le module de thread dans la bibliothèque standard Fournit des primitives de concurrence et existe depuis un certain temps. Il y a aussi troisième Party Bibliothèques qui fournissent des API de simultanées de niveau supérieur / différents.
Mais ça sonne comme si vous êtes Conflation de la concurrence et du parallélisme .
Ocaml bien sûr ne se met pas dans la voie du parallélisme. Vous pouvez exécuter OCAML sur des milliers ou des millions de machines en même temps. Il y a même MPI Bindings pour faciliter le programme pour des supercalculateurs de manière massivement parallèle. Mais la mise en œuvre actuelle de la référence OCAML ne parleura pas automatiquement les programmes concurrents, que je pense, c'est ce que vous êtes vraiment plus intéressé.
Vous pouvez être intéressé par multicore OCAML qui offre un meilleur support pour le parallélisme de la mémoire partagée, comme Les ordinateurs SMP sont devenus assez répandus au cours des deux dernières décennies et il serait vraiment agréable d'optimiser plus facilement pour eux. Ils semblent faire des progrès lents mais réguliers et essayer de bien réussir.