为什么我们需要“seq”或“pseq”与“标准杆”在哈斯克尔？
我试图理解为什么我们需要标准示例代码的所有部分：
a `par` b `pseq` a+b
为什么以下内容还不够？
a `par` b `par` a+b
上面的表达式看起来非常具有描述性：尝试并行计算 a 和 b，并返回结果 a+b。仅仅是因为效率的原因吗：第二个版本会触发两次而不是一次？
下面更简洁的版本怎么样？
a `par` a+b
为什么我们需要确保 b 在 a+b 之前计算，就像在原始标准代码中一样？
I'm trying to understand why we need all parts of the standard sample code:
a `par` b `pseq` a+b
Why won't the following be sufficient?
a `par` b `par` a+b
The above expression seems very descriptive: Try to evaluate both a and b in parallel, and return the result a+b. Is the reason only that of efficiency: the second version would spark off twice instead of once?
How about the following, more succinct version?
a `par` a+b
Why would we need to make sure b is evaluated before a+b as in the original, standard code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好的。我认为以下论文回答了我的问题： http://community.haskell.org/~ simonmar/papers/threadscope.pdf
总之，
和 的
问题在于缺乏评估顺序。在这两个版本中，主线程都会立即在
a（有时是b）上工作，导致火花立即“消失”，因为不再需要启动一个线程来评估主线程已经开始评估的内容。原始版本
确保主线程在
bbeforea+b上工作（否则将开始评估a相反），从而使 Sparka有机会具体化为线程以进行并行评估。Ok. I think the following paper answers my question: http://community.haskell.org/~simonmar/papers/threadscope.pdf
In summary, the problem with
and
is the lack of ordering of evaluation. In both versions, the main thread gets to work on
a(or sometimesb) immediately, causing the sparks to "fizzle" away immediately since there is no more need to start a thread to evaluate what the main thread has already started evaluating.The original version
ensures the main thread works on
bbeforea+b(or else would have started evaluatingainstead), thus giving a chance for the sparkato materialize into a thread for parallel evaluation.将并行评估 a 和 b 并返回a+b，是的。
然而，其中的pseq确保在a+b之前对a和b进行求值。
有关该主题的更多详细信息，请参阅此链接。
will evaluate a and b in parallel and returns a+b, yes.
However, the pseq there ensures both a and b are evaluated before a+b is.
See this link for more details on that topic.
a `par` b `par` a+b会为a和b创建火花，但是a+b> 立即到达，因此其中一个火花将失败（即，它在主线程中进行评估）。这样做的问题是效率，因为我们产生了不必要的火花。如果您使用它来实现并行除法 &征服那么开销将限制你的加速。a `par` a+b看起来更好，因为它只产生一个火花。但是，尝试在b之前计算a将会导致a的火花失败，因为b没有Spark 这将导致对a+b进行顺序评估。将顺序切换为b+a可以解决这个问题，但作为代码，这不会强制排序，Haskell 仍然可以将其计算为a+b。因此，在尝试计算
a+b< 之前，我们会执行a `par` b `pseq` a+b来强制在主线程中计算b。 /代码>。这使得在我们尝试评估a+b之前，a火花有机会实现，并且我们没有创建任何不必要的火花。a `par` b `par` a+bcreates sparks for bothaandb, buta+bis reached immediately so one of the sparks will fizzle (i.e., it is evaluated in the main thread). The problem with this is efficiency, as we created an unnecessary spark. If you're using this to implement parallel divide & conquer then the overhead will limit your speedup.a `par` a+bseems better because it only creates a single spark. However, attempting to evaluateabeforebwill fizzle the spark fora, and asbdoes not have a spark this will result in sequential evaluation ofa+b. Switching the order tob+awould solve this problem, but as code this doesn't enforce ordering and Haskell could still evaluate that asa+b.So, we do
a `par` b `pseq` a+bto force evaluation ofbin the main thread before we attempt to evaluatea+b. This gives theaspark chance to materialise before we try evaluatinga+b, and we haven't created any unnecessary sparks.