Re: [心得] C++17 execution policy

[IKAFIRE (沒有)]

因為推文感覺問題描述不清楚，乾脆回一篇問問題

看完這三個policy之後對於他的設計感到有點疑惑，因此跑回去看draft

這是今年二月的版本

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0024r1.html


前一篇已經把這個草稿的精髓描述過了

我在這邊只節錄草稿中對於每個policy效果的描述

##sequential_execution_policy

The invocations of element access functions in parallel algorithms invoked
with an execution policy object of type sequential_execution_policy are
indeterminately sequenced (in) the calling thread.

基本上似乎是個fallback用的policy，讓你在不改變呼叫形式的情況下也可以避免平行化

只是有個疑問，為什麼要設計成「不保證執行順序 (indeterminately sequenced)」呢？

有趣的是在2015的初稿中，原本是保證依序執行的，不知甚麼原因被改掉了


##parallel_execution_policy

The invocations of element access functions in parallel algorithms invoked
with an execution policy object of type parallel_execution_policy are
permitted to execute in an unordered fashion in either the invoking thread or
in a thread implicitly created by the library to support parallel algorithm
execution.

還蠻好想像的行為，沒甚麼問題


##parallel_vector_execution_policy

The invocations of element access functions in parallel algorithms invoked
with an execution policy of type parallel_vector_execution_policy are
permitted to execute in an unordered fashion in unspecified threads, and
unsequenced with respect to one another within each thread.

問題來了，這個policy的優點何在？

乍看之下與parallel_execution_policy相較沒有額外的好處，還會引入很多問題

例如前篇也提過的，許多synchronization都可能會變成deadlock

甚麼樣的情況下會不用上一個policy而採用這個？

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.176.119.253
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1463423025.A.33A.html
推 LPH66: 也許是讓迴圈能被 vectorization (向量化)?
→ LPH66: 就是每次迴圈利用 SIMD 暫存器一次跑多個循環這樣
→ LPH66: 沒有這條保證的話, 如前文所言亂序必須是拆 thread 才會有
→ LPH66: 拆 thread 就會有一些 sequence 上的問題是 vectorization
→ LPH66: 所無法保證的
推 lsc36: 可以讓compiler改變執行順序來加速
→ IKAFIRE: 感謝解答