Performance cpu utilization 5ghz

There is an indication. In fact, in V6 there are some components already multi-threaded.

What encouraging news - thanks. I was not aware of these changes. Here’s hoping more will be forthcoming soon.

I’ll be looking out for more dot decorations.

We just need samples that show components running slowly so we can see if multi-threading them improves their situation.

I think I’ll be able to provide you some samples. I presume you’ll want the GH file with all data internalized, along with specs on my CPU & RAM .

Would a GH file that has an SDiff that takes 44.2 seconds on a 3 GHz Intel i7 CPU be helpful for you?

Sure; I don’t have any specific requirements for how to get definitions. Internalized probably makes things easier since it would be one file.

Here’s a piece of code that, when run with the slider settings indicated, takes most of an hour to complete the ‘SUnion’ (and ‘SrfSplit’ and ‘SrfMorph’). Ah, but these components are not yet on the multi-threaded list

  • ‘# Horiz.’ = 27
  • ‘# Vert.’ = 33
  • ‘H Size’ = 1.3
  • ‘V Size’ = 1.4
  • ‘depth’ = 0.1
  • ‘height’ = 2.0

vase_2017Nov12a


SrfMorph_2017Nov14a.gh (23.4 KB)
(updated later to simpler version)

Joseph’s example is one he helped me develop. Here is a slightly different variation that uses Sdiff as the final component.
Capture

Sdiff-50ms.gh (23.6 KB)

My system has an Intel I7-3770S CPU clicked @ 3.10 GHZ with 16 GB RAM and an nVidia GT750 video card driving 2 monitors. I’ve got quite a few GH files like this so I can provide more if you want them.

To give credit where it’s due, I lifted key parts of that code from Lorenz Weiss, along with bits (‘Consec’) I added in this thread:

Wow! thanks for all the information guys. I’ll have to check out your suggestions.

Here is an example of a relatively simple, small bit of GH code that, through ‘Mirror’ and ‘Graft’ is generating 67,734 curves (sixty-seven thousand+!), yet only 22 are visible. All the rest are useless duplicates. Very slow response to changing any parameters.

Note that a component may take a long time doing a single iteration. If a component is slow yet the tooltip claims that it ran once (or any small number of times) then it cannot be sped up by making it multi-threaded. In these cases the only option is to make the underlying operation in Rhino itself multi-threaded and that may be very difficult and sometimes impossible.

Examples of this are solid booleans involving many inputs. Each union or difference changes the underlying shape potentially affecting all subsequent unions or differences, as such it is nearly impossible to parallelize this.

is an excellent point; thanks for making it clear David. When I made the part I posted above I was thinking “wouldn’t it be nice if GH could separate out the processing for each addition/subtraction, and then do 8 at a time”, sort of like how Photoshop divides up an image into separate pieces and parallels those.

But you are totally correct - in the Photoshop case the underlying object always stays the same, but with geometry it is very difficult or impossible to predict if any one Boolean operation would make a change that affects a subsequent one.

I guess one way to tell this might be to see if any of the addition or subtraction objects intersect, but of course doing that would add a whole new set of Boolean calculations, and that would be totally self defeating.

3D sure is fun, isn’t it?

This is exactly the case with the sample that @Birk_Binnard posted. The SDiff component only ran once which means we can’t multi-thread it at the component level.

There are potential optimisations even here, for example if the bounding boxes of all the cutting shapes are disjoint then perhaps part of the process can be parallelised. However it might also make sense to move the parallel code even deeper than the solid boolean method. For example into the surface-surface-intersection code. I do not know to what degree really low-level stuff like this has been made multi-thread aware in Rhino6, but I do know the maths boffins are working on making these sorts of improvements.

Though it is true we can not multi-thread solid boolean methods, we can, however, spread branches of inputs across threads (thank you data trees). For example, when perforating individual panels, each with their own set of shapes to be differenced, you can run the boolean process for each panel on it’s own thread. It’s not truly multi-threading the boolean operation, but still runs much faster for the branched use case. In fact, I imagine this could help any component that could not otherwise be multi-threaded.

Here is a generic swiss-cheese example with 64 slices:

I’ve attached the GH file for this example here:
RecursiveBooleanExample.gh (15.3 KB)

A side note: the boolean difference method employed in the definition is done recursively so that any shapes that fail to difference can be discarded to a list that can be used for troubleshooting without dumping the whole process (sphere in red). This takes a little longer than difference-ing the whole list at once, but it’s negligible and the troubleshooting benefit has proven useful for me.

2 Likes

So I had this idea: If Rhino and Grasshopper are single threaded programs (mostly) and HyperThreading “splits” your core in half, does that mean that they only utilise half of the core? Well… I tested: with HyperThreading ON I had around 12-15% CPU utilisation (i7 4770K, quad core) while performing some calculations in Rhino or Grasshopper. I set HyperThreading to OFF and now it get around 25-27% CPU utilisation and it feels faster and smoother. Am I imagining it or do you guys think my thinking has some logic? (I’m not computer scientist)

Hyperthreading is pretty much a scam as I understand it.

I suspected the same - the tasks we run in Rhino/GH just don’t match the performance benefits of hyper threading - I disabled it today and like you now see Rhino using a complete core instead of half - 25% usage rather than 12.5% of total processors in my 4 core i7 machine.

Marketing is evil.

Cheers

DK

Hmm you would think so but I had a dual 10-core Xeon machine at a job and it somehow squeezed a modest but definitely noticeable extra performance–10, 15%? You could see on the UPS it was pulling more watts, it was shocking–out of Brazil rendering, the last thing you would think would actually need this.

Guys, hyperthreading doesn’t use “half a core” on single core tasks, that makes no sense. It’s SHARING CPUs doing two things at once–the same thing the Operating System does, implemented at the CPU level.

1 Like