V6 Feature: Multi-threaded GH Components

Serengeti (Rhino WIP)
21

Hi Steve, thanks for the explanation. Intuitively I would have imagined that it works exactly the other way round.
Solving once -> multi threaded, dealing with the threads internally
Solving multiple times -> not multi threaded.

Ideally, both cases should be multi threaded, if possible.

22

@stevebaer Regarding the contour component, I tried to reproduce what @Angel is reporting, but was not able to. With the second example, I get to around 25% CPU usage today. There is some multi threading happening, but not as much as in the first example, where I get 80% CPU usage.

@Angel, the 12.5 CPU usage hints at one core being used only. I am having 8 cores, so 100% / 8 = 12.5%. Maybe your Xeon has four cores?

23

I appreciate this will be implemented as a standard. Not sure if that is in anyway helpful for anyone, but I wrote a blog post some time ago on our experience while using async components http://fucture.org/matas-ubarevicius/2016/05/23/async-grasshopper-components/

We use similar method in RAPCAMā€™s v5 Rhino grasshopper for Internet based validations and some intense calculations, which donā€™t block UI interactions while calculations are performed in parallel tasks. This works quite nicely.

24

Thanks for the post. We were able to make everything much simpler by adjusting Grasshopper to call SolveInstance in two passes when your component implements the new IGH_TaskCapableComponent interface (and the option is enabled for your component).

  • The first pass is used to build a calculation task for every iteration. Each iteration could launch further sub-tasks if it makes sense.
  • The second pass gets results from these tasks and sets IGH_DataAccess output

This makes every iteration potentially computed in a separate task and the output data structure is exactly the same without any extra effort.

25

That sounds amazing, really looking forward, this will be a great improvement for larger computations and general UX of gh. I will start migration from v5 to v6 asap just for this :slight_smile:

26

Please hold off on migrating based on the document I provided. I think there are a few changes I want to make in the base class that will simplify the code a little more. Iā€™ve updated a few more components this week and there is a bit of unnecessary repetition that I think I can remove.

27

No prob, will be following this thread for updates and do some testing, thanks!

28

It would be nice, but I wonā€™t be able to make that change for the ā€œBoundary Surfacesā€ component. This component works on a single large collection of curves and tries to figure what to do for all of these curves at once. Consider the case of a small circle inside of a larger circle. The interdependencies of these curves in the calculation makes multi-threading at the lower level difficult.

Fortunately, the story will be different for others components.

29

9 posts were split to a new topic: GH Feature Request: Parallel Groups

30

Update (Sept 5, 2017)

The Sept 5, 2017 WIP now includes an additional 10 components that use multiple threads to solve. Here are the additional components that could use some ā€œkicking of the tiresā€ for multi-threaded solving.

  • Mesh | Plane
  • Brep | Line
  • Brep | Curve
  • Brep | Brep
  • Brep | Plane
  • Curve | Curve
  • Curve | Curves
  • Point in Brep
  • Point in Breps
  • Curve Self-Intersection
3 Likes
32

HI Stevebaer
I use the Contour component,Use multithreading to calculate the results are not the same.

111111
111111.jpg1668Ɨ572 71.8 KB

Multi-threaded test.gh (7.3 KB)
Multi-threaded test.3dm (26.3 KB)
ā€”ā€”NARUTO

34

Thanks Naruto, Iā€™m investigating this

36

This was actually available in last weekā€™s WIP, but I forgot to mention it. David and I added converted another set of components to be able to use multiple threads for solving. The current list is:

  1. Curve | Plane new
  2. Project Curve new
  3. Pull Curve new
  4. Split with Brep new
  5. Shatter new
  6. Split with Breps new
  7. Trim with Brep new
  8. Trim with Breps new
  9. Area new
  10. Area Moments new
  11. Volume new
  12. Volume Moments new
  13. Brep Closest Point new
  14. Mesh | Plane
  15. Brep | Line
  16. Brep | Curve
  17. Brep | Brep
  18. Brep | Plane
  19. Curve | Curve
  20. Curve | Curves
  21. Point in Brep
  22. Point in Breps
  23. Curve Self-Intersection
  24. Contour
  25. Dash Pattern
  26. Divide Curve
  27. Boundary Surface
5 Likes
37

Iā€™m having some problems trying to use the Parallel option for the BREP | Line and BREP | Curve components ā€¦ basically Rhino ā€˜stops workingā€™ using either of them, but running single-threaded works. Calculation is ~6.4M lines intersecting a BREP ā€¦ although iā€™d like to actually check the 16 individual faces of the BREP, but first things first ā€¦

Related - is there any chance Mesh | Ray could be next on the list of threaded components? In the same script Iā€™m currently testing 2818 rays from 4771 points for intersection with a (rather large) mesh - the ~13.4m tests take ~4 minutes so iā€™d like to get this multi-threaded

1 Like
38

Has this list expanded?

39

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

40

Do you have parallel faces on the Brep?

// Rolf

41

@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.

42

Filed under RH-43240 and RH-43241.