Computer speed for flow along surface so slow?

Hi everyone. So I just had a pretty stout computer built for me. It’s a 5900x with an rtx3080 video card and 32gb of ram with a 1tb m.2 hard drive. Suffice it to say it’s pretty fast. When flowing some snakeskin on a ring for a tutorial I’m following it’s taking like 10+ minutes to compute. But when I check my CPU load it’s only at 6% so it’s barely working. I was wondering if this is normal or is there a setting I can change to speed things up?

Hi Jacob,

I guess you have a 16 core setup.
As operations in Rhino are almost exclusively single core, what you see is 1 core at max capacity ( 100/16 = 6.25)
There is not much you can so to speed flow along surface up.


Ok thanks, That kind of sucks though. Any chance Rhino devs are working to make rhino utilize more cores?

As far as I understand, for many geometric calculations it is not possible or efficient to multithread it.
As you see with rendering where calculating parts of the image can be distributed it’s apperently not so obvious to implement for -say- intersecting 2 surfaces.

I see Pascal is chiming in he might be able to give better insights

Hello - it can in some cases and not in others - where it makes sense to do so, Rhino does use more cores but the nature of cad calculations is (often) linear and not very susceptible to dividing up - I do not know specifically about the UDT (like FlowAlongSrf) functions however. I do believe there is more scope for taking advantage multithreading than is currently used in Rhino but it is not a ‘no brainer’ in most cases.


Ok, thanks guys. I was just surprised. This is the first time I’ve tried something like this. I was trying PJ Chen’s snake ring tutorial. I’m not quite there but close.

1 Like

The main reasons to have a high-end CPU with lots of cores is so that you have lots of PCI lanes for high end graphics, you can have lots of Chrome tabs open while working, and just why not the old story that lower-core-count CPUs are faster is a bit obsolete.

Basically anything to do with ‘content creation’ is really hard to parallelize, except for very specific tasks like rendering–and at that, only specific steps in that task! Some commands are multithreaded, I’m sure as opportunities arise they’ll add more, but that’s just the nature of what you are doing. 9 women can’t grow a baby in a month. And it’s not just the logic of each tool that mostly has no opportunity to divide and conquer, it’s that Rhino is at its core a database and you can’t have multiple threads messing around with that database willy-nilly. I mean sure large-scale web applications show it’s possible but you don’t want Rhino to cost a million dollars, need a rack of servers to run, and accept that once in a while your model will spontaneously turn into a cube because it can’t decide what to do with the competing requests.

In a nutshell.



more precisely in a womb :slight_smile:

1 Like

Sorry about slight OT, but this discussion on multi core utilization is very interesting.
I know of 3 areas in Rhino that can take andvantage of many cores now:

  1. Rendering
  2. ReduceMesh
  3. Meshing (if enabled via test command).

Do you know what else is currently taking advantage of it?

i want to ade my inquiry. in applications like batch booleaning many independent objects or modifying independent objects does rhino utilize multicore? these two objects processed by one core other objects parallely by another. or when printing pdfs or with any other batchlike operation when job can be split simply amongst more cores

One of the frequent processor-time consuming tasks we do is MergeAllFaces, often ran on many separate independent objects. Is this one using a multi-core for example?
It woud be handy to know which commands/operations do, which can’t, and where is some room for improvement and implementing it. I know it would be a lot of work to find out, but why not throw it out there…

If it was “simple” it would have been done ten years ago.

The only multithreaded operations are the ones everyone knows about.

ithink it is simple to split pdf printing when there is 100pdfs in queue so each core can parallelly export its portion.

Um sure in theory but I don’t think anything to do with PDFs or printing in Windows is advanced enough to have 100 instances trying to work at once…

It makes sense that many operations that are linear in nature can’t take advantage of many cores.
However I would imagine that commands that take either one or many objects to process at the same time, and the operation runs independently on each of the selected objects (like MergeAllFaces, or even FlowAlongSrf), they could be processed a core-per-object?
I don’t know Rhino’s inner workings but in my mind it works :slight_smile:

Shuure…but of course the computer still has to set up these separate threads, distribute the needed geometry to them all, and collate the results once they are all done. That’s a bunch of extra overhead that may not even result in a speed-up depending on circumstances.

1 Like