Are there any disadvantages of using the greedy policy as compared to the previous example?
ericwang
I have the same question.
The most obvious different between these 2 policies is which thread should perform sync and resume following instructions.
If assume the threads are in a shared memory environment, there seems to be no difference if another thread perform sync.
On the other hand, in "stalling" join policy, the initiate thread must keep waiting until all tasks done. It's not efficient.
cgjdemo
I think maybe one of the disadvantage of greedy policy is that we will lose cache locality if the thread which continues execution after sync is not the original thread. But I think most of time greedy policy has better performance than stalling join policy.
kk
If the work stolen is very small, then the greedy policy might not be ideal since the overhead of stealing that piece of work might be greater than the amount of time spent stalling and having the other thread finish the work instead.
Are there any disadvantages of using the greedy policy as compared to the previous example?
I have the same question.
The most obvious different between these 2 policies is which thread should perform sync and resume following instructions.
If assume the threads are in a shared memory environment, there seems to be no difference if another thread perform sync.
On the other hand, in "stalling" join policy, the initiate thread must keep waiting until all tasks done. It's not efficient.
I think maybe one of the disadvantage of greedy policy is that we will lose cache locality if the thread which continues execution after sync is not the original thread. But I think most of time greedy policy has better performance than stalling join policy.
If the work stolen is very small, then the greedy policy might not be ideal since the overhead of stealing that piece of work might be greater than the amount of time spent stalling and having the other thread finish the work instead.