Re: [心得] C++17 execution policy
原文 #1NERrsxa
※ 引述《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的初稿中，原本是保證依序執行的，不知甚麼原因被改掉了
如果你是問為什麼不改成sequential，那解答應該是
這樣跟不用execution policy一樣，那這樣就不需要有這個execution policy了
如果你是問為什麼不改成unsequenced，那解答應該是
標準應該增加一個std::unsequenced_execution_policy
（可針對block operation提升效能）
然後sequential_execution_policy名字應該要更改，因為原本的意思已經不見了
不知道這樣有沒有解答你的疑問
（底下新增Jared Hoberock的回答）
: ##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.
: 還蠻好想像的行為，沒甚麼問題
對
所以要用execution policy的人，應該先了解thread的概念
: ##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而採用這個？
vector<size_t> num{1,2};
vector<int> input{4,3};
vector<int> output(2);
for_each(par_vec,cbegin(vec),cend(vec),[&](const auto val){
//do something according to input[val]
//save result to output[val]
});
以這例子來說，parallel_vector_execution_policy能執行更快
因為每個func互不干涉（我已經給func需要的資料）
所以如果不用進行synchronize，用parallel_vector_execution_policy會更好
另外，還要提一點，如果你的func裡面有block operation
那使用parallel_vector_execution_policy應該會更快
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.251.48.57
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1463452515.A.0E1.html
推
05/17 10:39, , 1F
05/17 10:39, 1F
是的
→
05/17 10:58, , 2F
05/17 10:58, 2F
→
05/17 10:58, , 3F
05/17 10:58, 3F
→
05/17 10:58, , 4F
05/17 10:58, 4F
→
05/17 10:58, , 5F
05/17 10:58, 5F
我只看得懂前面那句話...
「因為要使用同個function signature，所以要增加一個非parallel的版本」
剩下的就看不懂了
推
05/17 11:25, , 6F
05/17 11:25, 6F
→
05/17 11:25, , 7F
05/17 11:25, 7F
→
05/17 11:27, , 8F
05/17 11:27, 8F
→
05/18 23:27, , 9F
05/18 23:27, 9F
From: Me
Hi, I am reading the C++ standard (about parallelism TS).
And, I am curious, why does the C++ standard use "sequential order" for
std::sequential_execution_policy at first in P0024R0.
But using "indeterminately sequenced" for std::sequential_execution_policy
later in P0024R1.
The reason I guess is
"if std::sequential_execution_policy executes in sequential order, the behavior
is as same as executing algorithm without using execution policy".
As a result, std::sequential_execution_policy should be different, that's why
it becomes indeterminately sequenced in P0024R1.
Is that right?
Thanks a lot.
--------------------------------------------------------------------------------
From: Jared Hoberock
I think that change was suggested by Jens Maurer. I think his concern was that
"sequential order" is not really defined anywhere in the standard, while
"indeterminately sequenced" is given a precise meaning elsewhere in the
document. The intent wasn't to change the technical content of the parallelism
TS, it was just to clarify the existing intention.
不知道這樣能不能回答你的問題
推
05/19 10:28, , 10F
05/19 10:28, 10F
目前看來是這樣
另一位大師表示：當初修改的確是因為這原因
所以，會改成indeterminately sequenced，只是因為當初標準沒有定義sequential order
推
05/20 11:52, , 11F
05/20 11:52, 11F
推
05/20 16:51, , 12F
05/20 16:51, 12F
※ 編輯: Caesar08 (1.161.57.133), 05/21/2016 19:59:40
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 3 之 3 篇)：