a1211094597

jlait
The downside of the merging, however, is if you have holes in your geometry. In this example the old scatter sop has left 8 holes in the point list. So the first thread will grab 1016 points from the first page and 8 points from the second page. This then locks the second page until the first thread is done. Normally this isn't noticeable as processing a page is very fast, but in a very expensive task like this it means that after all threads are done, one is stuck waiting for the first thread to complete. I didn't notice any difference on my 8-thread home machine, for example, as one has to wait for the second round to complete anyways; while my 12-thread linux machine has a big difference because we can complete the entire sequence in one burst vs two bursts.

If you use the new scatter sop you'll see the same performance, and slightly faster with my code. If you add a Sort SOP after the scatter, you'll force a defragment and close the holes and likewise get similar speed. I've added some notes to the bug to see if we can't get better heuristics to avoid locking a page like this. But this is all part of the eternal fight between grain-size and multithreading :> You have to chop up your work fine enough to things are balanced, but if you chop it too fine you die due to overhead. With VEX we have absolutely no idea how expensive your task will be. If doing really expensive stuff like this, you might be best using the By Number option to take control of the grain size and allow even finer grain threading.

The sort sop "Optimize Internal Vertex Order" option says that it will affect the linear vertex, but if you use "i@vertex_index = @vtxnum;" in wrangle, the index will not change while the Map offset will change(close the hole?).
As far as I know, the hole is some unaligned array(which keeps all values of all elements of particular types together.) when you delete some points/prims and sort node can alter the array. So the description of the sort node is wrong or？