loin de moi l'idée d'ouvrir une guerre de paroisses
D'un autre côté, il a déjà du faire face à des commentateurs défendant git, il craignait peut être que ce soit pareil ici (d'autant que les guerres de chapelle entre langage peuvent être âpres).
Qu'est-ce qui ne vas pas avec les threads?
Le parallélisme ? Les approches à la Lwt (ou Async) c'est pratique mais ça ne parallélise pas les calculs sur tous les core du CPU. J'ai l'impression que la propriété de commutativité entre patchs indépendants se prête bien à la parallélisation des calculs. Il y a bien le projet ocaml-multicore (encore chez OCaml Labs) à base de fibres mais il en est encore au stade de la recherche (bien qu'il avance sûrement).
À l'heure actuelle, il faut forker (comme dans cet exemple du benchmark game) pour faire du map-reduce en parallèle, ce qui n'est pas des plus adapté comme solution.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Repos
Posté par kantien . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
D'un autre côté, il a déjà du faire face à des commentateurs défendant git, il craignait peut être que ce soit pareil ici (d'autant que les guerres de chapelle entre langage peuvent être âpres).
Le parallélisme ? Les approches à la Lwt (ou Async) c'est pratique mais ça ne parallélise pas les calculs sur tous les core du CPU. J'ai l'impression que la propriété de commutativité entre patchs indépendants se prête bien à la parallélisation des calculs. Il y a bien le projet ocaml-multicore (encore chez OCaml Labs) à base de fibres mais il en est encore au stade de la recherche (bien qu'il avance sûrement).
À l'heure actuelle, il faut forker (comme dans cet exemple du benchmark game) pour faire du map-reduce en parallèle, ce qui n'est pas des plus adapté comme solution.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.