PDG | WEDGING A COMPILE SOP NETWORK
TOP Geometry SOP は、ネットワークのパラメータを Wedge しつつ、コンパイルされた SOP ネットワークを経由して入力を処理する方法です。この手法は、SOP の For-Loop ノードの代用となり、このアプローチの利点は、ネットワーク自体に依存することなく、パラメータの変化の設定および分析ができることで、 ネットワークはコンパイルされ、なおかつ、順次ではなく、並列実行されます。 このネットワークで使用するノードはコンパイル可能なノードでなければならないという制限がありますが、幸いにもSOPノードの殆どはコンパイル可能ですコンパイルしたSOP For-Loop をマルチスレッド用に設定すれば同様の制限とパフォーマンスを得られますが、こちらの方法の方が設定が簡単な場合が多いです。
このチュートリアルは、SOP と TOP の両方にある程度の知識があることを前提としています。 TOPの詳細については、PDG ラーニングパスをご参照ください。
コメント
GeorgeHulm 3 年, 9 ヶ月 前 |
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 年, 9 ヶ月 前 |
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.