Multi-threading C# components

I have been experimenting with multi-threading inside custom C# components. It can be a little unstable if you are calling through to an unsafe function in Rhino, but for the most part they work and allow you to utilise all the processors simultaneously. I wrote a little tutorial (with a sample version of the project to surface node, treaded) over at http://www.nzarchitecture.com/blog/index.php/2011/05/07/threading-g...

The C# component can be downloaded at parametric model.

Replies to This Discussion

Permalink Reply by Suryansh Chandra on September 22, 2011 at 10:31am

Thanks for posting this. I tried it onto another solar analysis component that I wrote, and the performance gains are massive: it went from a solving time of 9.7s to 1.1s -- ofcourse that's with 12 cores :)

But massively helpful for tasks that are not co-dependent/iterative. Obviously, debugging with this is a royal pain -- only possible if Rhino actually survives the bug (in most instances, it takes me straight to my desktop wallpaper!)

Permalink Reply by Daniel Davis on September 22, 2011 at 11:00pm

Wow I am surprised by how dramatic your performance gains were Suryansh. 12-cores sounds pretty outrageous but I guess it will be commonplace in a few years, so your project really underscores the significance of multi-threading. I suspect we might even reach a point where Grasshopper models evaluate faster than text-based scripts simply because the Grasshopper schema can be processed in parallel.

Know the crashing feeling well. Forgot if there was a try/catch segment in the code, it might stop some of the bad crashes?

Daniel

Permalink Reply by Rémy Maurcot on September 28, 2011 at 8:43am

Daniel is really interesting post, and I spent the afternoon to visit your links and try out various possible definitions.

I wonder if all the functions GH may be multi-threading?
With some functions of mesh explode the computation time, I know the complexity of programmed components in multi-threading.

Thank you in advance and the best.

Permalink Reply by Daniel Davis on September 28, 2011 at 6:16pm

Hi RhinoBridges,

> I wonder if all the functions GH may be multi-threading?

As I said in the post, it would be nice to have multi-threading but it is not realistic at the moment. Multi-threading in Grasshopper (or a Grasshopper plugin) can not be supported until Rhino itself is thread-safe. Parts of Rhino V5 are thread-safe but we will probably have to wait until Rhino V6 until all the functions in Rhino (and therefore GH) support mulit-threading.

Daniel

Permalink Reply by Rémy Maurcot on September 29, 2011 at 2:15am

Thank you for that comment, I would follow it closely.
To produce a pluggin in grasshopper, I wondered how workload was nécesssaires the integration of multi thread.

See you later, good work.

Permalink Reply by Philipp on September 29, 2011 at 3:55am

Hi Daniel. I wonder what about shaders. if it possible to use sheyders (graphcard) power within grasshopper for some specific purposes (not only for graphics) as we can do in VVVV

Permalink Reply by Daniel Davis on September 29, 2011 at 5:45am

Hi Philipp,

The Grasshopper VB/C# scripts can do anything the Microsoft Common Language Runtime allows and while I havn't done it myself, I suspect this includes running code on the GPU. I would be curious to see how VVVV handles this, I don't think you can just tell the GPU to run a Rhino command? My guess is that you would probably have to recreate the Rhino Command in something like OpenCL and then run the OpenCL. So imagine first writing your own brep-boolean code, and then making it thread safe, and then writing it in the OpenCL language. You might consider doing that if you were building a Rhino competitor, you wouldn't do that to save 10 seconds on a Grasshopper update cycle :)

Daniel

RSS