Illume presentation on Compile blocks.
Moving forward Houdini's move to SOPs 2.0 will continue on. For those of us interested in building tools for artists and TDs/TAs utilizing SOPs as verbs is going to be a critical tool in our arsenal.
Here is the pdf of the slides used in the presentation for reference.
Illume | Invoke Compile Blocks
2785 1 5-
- old_school
- スタッフ
- 2540 posts
- Joined: 7月 2005
- Offline
-
- Andr
- Member
- 900 posts
- Joined: 2月 2016
- Offline
I found the session quite intriguing, especially the part at 28:00 where Jeff discussed the reduced overhead of building compiled for-each blocks in the upcoming Houdini 20.
To get a better grasp of this overhead, I've tried comparing the performance of a compiled for-loop versus a non-compiled for-loop when both iterating over a SINGLE piece.
1) Am I on the right track here?
I've noticed that in this specific case, the non-compiled loop seems to have a slight advantage for a single iteration. However, it's worth noting that this isn't a typical scenario when working with for-loops (which usually iterate over multiple pieces).
2)This leads to my main question is: What exactly is the nature of the overhead associated with compiled for-loops?
Could it be related to the inherent overhead of the mere for-loop itself, especially when it needs to split the geometry into pieces and then merge them back together at the end?
I really wish Jeff is talking about this 😄 because that's a huge cost for operating normal for-loops and would be a godsend if it were reduced in Hou 20.
cheers
To get a better grasp of this overhead, I've tried comparing the performance of a compiled for-loop versus a non-compiled for-loop when both iterating over a SINGLE piece.
1) Am I on the right track here?
I've noticed that in this specific case, the non-compiled loop seems to have a slight advantage for a single iteration. However, it's worth noting that this isn't a typical scenario when working with for-loops (which usually iterate over multiple pieces).
2)This leads to my main question is: What exactly is the nature of the overhead associated with compiled for-loops?
Could it be related to the inherent overhead of the mere for-loop itself, especially when it needs to split the geometry into pieces and then merge them back together at the end?
I really wish Jeff is talking about this 😄 because that's a huge cost for operating normal for-loops and would be a godsend if it were reduced in Hou 20.
cheers
Edited by Andr - 2023年9月18日 04:44:50
-
- Quick Links