<div dir="ltr">Hi friends,<span style="color:rgb(140,140,140);font-style:italic;font-family:"JetBrains Mono",monospace;font-size:11.3pt">new_state = table[left_state * 4 + right_state]</span><div><br></div><div>I have rewritten the __parallel_reduce function for OpenMP to avoid using the reduction() clause. I think that OpenMP is not feeding the output values to the reduction in the way that one might think. I am tracking that problem in a different thread. In any case, the loop without the reduction, and then performing an explicit reduction at the end gets _much_ farther.</div><div><br></div><div>In this thread, I would like to talk about the is_partioned algorithm. Briefly, I can see that there is a main body which performs some processing and then returns a result which is a value in a lookup table.</div><div><br></div><div>The brick body for is_partioned will return one of:</div><div><div></div><div><pre style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt"><span style="color:rgb(0,51,179)">enum </span>_ReduceType<br>{<br>    __not_init = -<span style="color:rgb(23,80,235)">1</span>,</pre><pre style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt">    __broken,</pre><pre style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt">    __all_true,<br>    __all_false,<br>    __true_false<br>};</pre></div></div><div>In the case I am trying to debug there 521 elements. The simple, naive chunk partitioner I wrote breaks this up into two chunks: 0-511, and 512-521.</div><div><br></div><div>The first chunk comes back as "2" (__all_true) and "3" (__all_false) if I am reading the enum right. The reducer is called with __reduction(2,3) which performs the following table lookup:</div><div><pre style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt"><span style="color:rgb(140,140,140);font-style:italic">new_state = table[left_state * 4 + right_state]</span></pre></div><div>In this case, it looks like it result in table entry 11:</div><div><span style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt"><br></span></div><div><span style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt">_ReduceType __table[] = {</span></div><div><span style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt"> __broken,     __broken,     __broken,     __broken, __broken,  __all_true,</span></div><div><span style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt"> __true_false, __true_false, __broken,     __broken, __all_false, __broken,</span></div><div><span style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt"> __broken,     __broken,     __true_false, __broken</span></div><div><span style="color:rgb(8,8,8);font-family:"JetBrains Mono",monospace;font-size:11.3pt">};</span></div><div><br></div><div>Which turns out to be __broken. However, when I run the brick body on the entire range at once, it results in "3". This seems to indicate that the algorithm is very sensitive to how the range is chunked. I looked at the TBB implementation and it seems to create a blocked range with a grainsize of 1. That seems wrong, since the scheduling overhead would be enormous, so clearly there is something going on that I don't understand.</div><div><br></div><div>However, since the reduction of two arbitrary chunks of a range appears to give an answer that is different from the reduction of a symmetric split, it seems like that may be a requirement. Is that true? Does __parallel_reduce need split the range evenly in order to perform correctly?</div><div><br></div><div>-={C}=-  </div></div>