V6 Feature: Multi-threaded GH Components

No; is there a component that you need us to investigate?

Do you have parallel faces on the Brep?

// Rolf

@DavidRutten would it be possible to parallelize the Surface Geodesic component? This is a computationally heavy component which I suspect could be easily parallelized. While you’re at it, I’m wondering if you can expose the tolerance value in the component?

Surface Split is another component which could be parallelized and is often computationally expensive.

Filed under RH-43240 and RH-43241.

hi … sorry my email notifications are still not working

I don’t have the case in front of me, but i suspect there are parallel faces and even if not, it is likely that other models would include parallel faces

(it is building envelope analysis, so pretty good chance they are ‘box-like’)

Is it possible to parallelize the mesh collision component?

Have you considered an “Auto” mode for multithreading? I have found that when dealing with a small number of geometries, many of the MT operations are considerably slower than their single-threaded counterparts (e.g., 254ms vs 15ms) because of the set-up time for the threads themselves (as outlined in previous discussions/posts w/ @stevebaer).

In an ideal world, a scalable definition would use Single threading with a small number of input objects and Multithreading with a large number, and there is likely a set of thresholds that represents the breakeven point between the two. I understand that this breakeven point may differ considerably between components and may even be complicated by the fact that some multithreading components can accept different kinds of input types, and therefore further complicate the breakeven threshold.

That said, I could see some sort of one-time regression analysis done on this problem in a sandbox scenario that could determine of a set of thresholds based on an accounting of the input geometry/data, which would be prebaked by McNeel after a set of tests. Those thresholds would simply apply ST vs MT based on those thresholds, and therefore scale appropriately as the amount of input data increases/decreases.

Right now I am considering implementing a hack that essentially routes data into a ST version of the component or a MT version based on my own realworld tests… but boy, it would be nice if GH could handle that.

:slight_smile:

Cheers,
Marc

After testing some GH0.9.0076 => 1.0 migrations, we have found that components that are now MT-capable have multithreading enabled by default. This is becoming a major problem for us.

As this list of enabled components grows, the challenges updating old definitions grow as well. I would like to make a case to have MT set to OFF by Default, or at the very least on any components that were written with an older version of GH (and therefore were not explicitly enabled).

HERE’S WHY:

Many of our definitions actually do a significant amount of work on smaller amounts of geometry, and due to the overhead of setting up the threads (and not making up the difference in performance) MT operations are actually slowing down performance tremendously (adding 2s to a 300ms definition, for instance). This means we have to search our definitions for MT components, test them in various scenarios, and then decide whether MT is a benefit or a hindrance.

Moreover – As it stands, with MT ON by default, we will be subject to sudden slow-downs when new components are MT-enabled, and the end-users of our GH applications will experience UX issues (and more importantly, unreliable and inconsistent UX over time and over GH versions) until we are able to identify new MT components, track them down, evaluate, and push a new version to our users.

This is a real maintenance issue moving forward. Ultimately, if some kind of Auto mode is implemented to make a best-fit execution scenario, this problem will be solved, but in the meantime it seems that setting a default to OFF would be a good solution.

Thanks,
Marc

2 Likes

I wonder how hard the analysis would be. It may be possible to set up something that runs the solution four times with the MT feature on and four times with it off and then chooses based on results from that.

I don’t see any problem with defaulting to off (or even making the default an option). @DavidRutten any opinions here?

Awesome, thank you for considering it.

Another two cents: default as an option would be great but if it could be OFF by default, that would reduce the amount of tinkering that a large organization has to do when deploying Rhino at scale. I don’t mind if advanced users want to turn it on, as it’ll be easier to explain to them the ramifications of their decision and why our standard tools are more sluggish than their amateur colleagues… :slight_smile:

Cheers,
Marc

No opinions. I can add an option for this into the Grasshopper preferences Solver category if you want, or we can just default to off the hard way.

Default to off is… should be the default approach. That simplifies all aspects of it.

Also given the fact that parallel processing nearly always is depending on factors not obvious until testing, OFF should really be the default.

Only conscious design decisions (often after some testing) typically motivates going parallel.

// Rolf

I’m fine with that. We needed this to be on to make sure it actually worked on user’s computers and we are well beyond that phase now. An analysis tool could probably be developed to help assist in determining which components for a given definition benefit from having MT turned on.

2 Likes

Would love to hear when you think this change will happen. I am going through another large migration, which means searching through a 22,000 component definition for a list of components that I think might be suspects. Would be great to be able to skip this step in future migrations.

Thanks!

Marc

1 Like

@stevebaer @DavidRutten I’d like to put another vote in for threading Mesh | Ray Intersect. Use this all the time with large meshes and giant sets of points.

And I’d vote for a parallel Mesh | Line Intersect which would provide a limited depth. Mesh | Ray has a starting point (which is good) but no limit to the ray’s extent

// Rolf

1 Like

After a while I tried implementing multithreaded component myself by following this article

But this seems to only explain the process around one task that is created in InPresolve phase.

I wonder how one should go about creating multiple tasks, adding them to TaskList and then awaiting on completed result to set the data, It may be that I miss something here. Thanx.

Yes please. We could explore a lot of visually interesting solutions with mesh Boolean being near real-time.

@stevebaer @DavidRutten

Still, there is a difference in results.

It might be possible to make multi-tread on the ‘Split Multiple Brep’ component. For large scale (urban) operations it would be extremely useful.
Thank you