V6 Feature: Multi-threaded GH Components

unhandled

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


(Steve Baer) #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:


(Steve Baer) #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!


(Steve Baer) #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.


(Steve Baer) #29

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


(Steve Baer) #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

GH Feature Request: Parallel Groups
(Steve Baer) #31

(NARUTO) #32

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


Multi-threaded test.gh (7.3 KB)
Multi-threaded test.3dm (26.3 KB)
——NARUTO


(Steve Baer) #34

Thanks Naruto, I’m investigating this


(Steve Baer) #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

Performance cpu utilization 5ghz
#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


#38

Has this list expanded?


(Steve Baer) #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.


(David Rutten) #42

Filed under RH-43240 and RH-43241.