PDG | WEDGING A COMPILE SOP NETWORK
Learn how to setup a Top Geometry SOP to process its input through a compiled SOP network, while wedging the parameters of the network with TOP attributes. This technique can be used in replacement of a SOP For-Loop. One benefit of this approach is that the parameters being varied can be set and analysed independent of the network itself. Also, the network is both compiled and then run in parallel as opposed to sequentially. A limitation is that the nodes used in the network must be compilable, but fortunately most SOP nodes are. A compiled SOP For-Loop set to be multi-threaded will have the same limitations and performance, though users may find this method easier to setup.
This tutorial assumes some familiarity with both SOPs and TOPs. For more information on TOPs, please go to the PDG Learning Path.
COMMENTS
GeorgeHulm 3 years, 10 months ago |
Hi Michael, thanks for this Tutorial.
I'm using compile blocks and tops, but I haven't combined the two before, it seems like it could be great for doubly speeding up slow networks!
My understand was that Compile and tops did somewhat similar things, since both allow you to take advantage of multithreading. And I thought that tops in a way superseded the compile node, but now I understand there are some benefits to compiling that tops doesn't cover.
My question is. Can I remove the "compile" block from your network, and still use the "invoke" method to wedge some geometry to produce lots of variations, and will this still benefit from being sped up by multitrheading as opposed to a simple "for-each-loop" ?
The reason I ask is because I'd like to multithread some nodes that don't currently support being compiled.
Thanks for the informative video
michaelb_ 3 years, 10 months ago |
Hi, so a Compile Block will basically turn all the node operation inside it to a single operation. This does allow it to be multi threaded, but has performance enhancements in its own right. Typically these are small speed boosts, and for many networks it doesn't matter enough to warrant throwing compile blocks around everything. For large networks or networks that need to run many many times it can add up however.
The Invoke TOP runs each of its tasks in the current process on separate threads. Because Compile Blocks can be multi threaded, that can be run through it. However, arbitrary sop networks cannot be multi threaded in general. So the answer to you question is no :)
However, the Invoke TOP is unique in that its work takes place in the current process on separate threads. In general TOPs achieves parallelism by doing running its work items in separate processes. Since sharing memory between processes is difficult, the way results are passed around is by writing and reading from disk. This is why Output/Input files in TOPs are so common.
So what you could do is use a ROP Geometry Output TOP to run your network if it can't be compiled. This will run the network in parallel in separate processes. The downside to this is that each process takes some extra time to start, and you will have to read the results in from disk to bring them back together. You can start a ROP Service to reduce the startup overhead, and you can use a Wait For All and a Geometry Import TOP to merge the results back together again when the work is done.
That ran longer than expected, but I hope that paints a clearer picture :)
Please log in to leave a comment.