Pourquoi avons-nous besoin de 'seq' ou 'pseq' avec 'par' dans Haskell?

Question

J'essaie de comprendre pourquoi nous avons besoin de toutes les parties de l'échantillon standard code:

a `par` b `pseq` a+b

Pourquoi ne pas les points suivants sont-ils suffisants?

a `par` b `par` a+b

L'expression ci-dessus semble très descriptif: Essayer d'évaluer à la fois a et b en parallèle, et de retourner le résultat a+b. Est la raison seulement de l'efficacité: la deuxième version de l'étincelle s'éteint deux fois au lieu d'une fois?

Comment au sujet de la suivante, plus succincte version?

a `par` a+b

Pourquoi aurions-nous besoin pour assurez - b est évaluée avant d' a+b comme dans l'original, code standard?

Answer 1

Ok. Je pense que le présent document répond à ma question: http://community.haskell.org/~simonmar/documents/threadscope.pdf

En résumé, le problème avec

a `par` b `par` a+b 

et

a `par` a+b

c'est l'absence de commande de l'évaluation. Dans les deux versions, le thread principal se met au travail sur a (ou, parfois, b) immédiatement, provoquant des étincelles "pétiller" immédiatement car il n'est plus nécessaire pour démarrer un thread à évaluer ce que le thread principal a déjà commencé à évaluer.

La version originale

a `par` b `pseq` a+b

assure le thread principal fonctionne sur b avant a+b (ou d'autre aurait commencé l'évaluation de a au lieu de cela), donc de donner une chance à l'étincelle a se matérialiser dans un thread pour l'évaluation parallèle.

Answer 2

 a `par` b `par` a+b 
 

évaluera a et b en parallèle et renvoie a + b , oui.

Cependant, le pseq garantit que a et b sont évalués avant a + b .

Voir ce lien pour plus de détails sur ce sujet.

Answer 3

a `par` b `par` a+b crée des étincelles pour les deux a et b, mais a+b est atteint immédiatement si l'un des étincelles s'essoufflant (c'est à dire, il est évalué dans le thread principal). Le problème, c'est de l'efficacité, que nous avons créé inutile de faire des étincelles. Si vous êtes en utilisant ce à mettre en œuvre en parallèle divide & conquer puis la surcharge de limiter votre speedup.

a `par` a+b me semble bien meilleure, car il ne crée un seul allumage. Toutefois, la tentative d'évaluer a avant b s'essoufflant l'étincelle a, et en tant que b n'ont pas d'étincelle, il en résultera séquentielle de l'évaluation de l' a+b. Changement de l'ordre d' b+a permettrait de résoudre ce problème, mais en tant que code ce n'est pas le respect de la commande et Haskell peut encore évaluer qu'en tant que a+b.

Donc, nous n' a `par` b `pseq` a+b pour forcer l'évaluation de l' b dans le thread principal avant de tenter d'évaluer a+b. Cela donne à l' a étincelle chance de se concrétiser avant d'essayer d'évaluation a+b, et nous n'avons pas créé inutile d'étincelles.