CPU is the bottleneck?

[O.Tan]

This is beyond my scope of understanding but I would like to hear from Fusion dev side on why is CPU the bottleneck, I can understand for softwares like SolidWorks and such, but does Fusion has the same issues with SW as well? Is this an inherit compromise when it comes to CAD softwares?

http://www.develop3d.com/hardware/review-amd-radeon-pro-wx-5100-3D-design-CAD-GPU

[Beyondforce]

CAD programs using math and all kinds of algoritmes, and therefor they are using a lot of cpu. The more complex the object is the more cpu power you gonna need. Which is why we need to simplify our sketches.
With that said, it is also dependens on how the software utilises the multi core processors as well.
If you are not doing a lot of rendering and animation, then your GPU won't be affected as much as the CPU.
Another thing is, try not to run too many programs at the same time you are working with Fusion, because that can really effect the performance.

[kb9ydn]

Not only does CAD software use a lot of math, it also tends to require that math to be done in a specific order due to how history based modelling works.  So that there isn't much opportunity to take advantage of multiple CPU cores.  That's why you're better off (many times) to use a CPU that has a higher clock speed instead of one with lots of cores.

For complex models direct modelling will be much faster because there are fewer dependencies and it doesn't have to solve a long chain of features.

C|

[TrippyLighting]

---

@kb9ydn wrote:

For complex models direct modelling will be much faster because there are fewer dependencies and it doesn't have to solve a long chain of features. 

---

Spot on! 

In Timeline mode it depends on the dependencies. @innovatenate had explained this very nicely in a thread I cannot locate at the moment.

Most CAD software use math in a way that is hard to break up so it cannot really run multithreaded in parallel on several cores. It also very often does not utilize multithreading.

Rendering is a very different animal. The Fusion 360 render engine is CPU only and uses all cores including multithreading.

I watch this quite often on my iMac and it is interesting to see that for some tasks, for example when converting a complex T-Spline it seems all cores are used for a short amount of time.

[O.Tan]

@Beyondforce thanks for replying, but the answers I'm looking for is more inline towards @kb9ydn and @TrippyLighting

Not only does CAD software use a lot of math, it also tends to require that math to be done in a specific order due to how history based modelling works.  So that there isn't much opportunity to take advantage of multiple CPU cores.  That's why you're better off (many times) to use a CPU that has a higher clock speed instead of one with lots of cores.

Most CAD software use math in a way that is hard to break up so it cannot really run multithreaded in parallel on several cores. It also very often does not utilize multithreading.

 Aaah, good point regarding the math having to be done in a specific order making it harder to broken into a multithreaded parallel processes. And yeah, niche workstation manufacturer like Workstation Specialists purposely specced their desktops with higher clock speed and overclocks them for you, guess you really can't have a PC to do both render and CAD, it'll probably be either optimised for CAD or render but not both. 

For complex models direct modelling will be much faster because there are fewer dependencies and it doesn't have to solve a long chain of features.

Yup, I noticed this especially with Fusion 

Rendering is a very different animal. The Fusion 360 render engine is CPU only and uses all cores including multithreading.

Yeah, it appears so. Though funny enough for rendering, people would want the GPU to be able to do it as well since results has shown that if you're restricted to a Quad Core Dual Thread CPU, usually a GPU render will be faster. It's only when a 12 Core CPU is involved where CPU render really starts to fly.

I watch this quite often on my iMac and it is interesting to see that for some tasks, for example when converting a complex T-Spline it seems all cores are used for a short amount of time.

Aah interesting, guess in areas where they can split up the processes, they'll do it.

[TrippyLighting]

---

@O.Tan wrote:

Yeah, it appears so. Though funny enough for rendering, people would want the GPU to be able to do it as well since results has shown that if you're restricted to a Quad Core Dual Thread CPU, usually a GPU render will be faster. It's only when a 12 Core CPU is involved where CPU render really starts to fly.

---

The subject of CPU vs. GPU rendering if you take it beyond the usual marketing rubbish is a bit more complex. When choosing the right tool one needs to be aware of what one is rendering. If you render opaque objects that are lit by large light sources then the usual path tracing is fine and that can be done easily on a GPU. Most demos I've ever seen are done like that. If you want subsurface scattering, caustics and dispersion, the the brute force path tracing fails and other algorithm do this better.

Once you get to bidirectional path tracing with metropolis light transport the algorithms and memory requirements are too big to fit into the small GPU kernels and you are back to the CPU.

Sometimes you get to these limitations rather quickly.

[anandjoshi]

---

@TrippyLighting wrote:

---

@O.Tan wrote:

Yeah, it appears so. Though funny enough for rendering, people would want the GPU to be able to do it as well since results has shown that if you're restricted to a Quad Core Dual Thread CPU, usually a GPU render will be faster. It's only when a 12 Core CPU is involved where CPU render really starts to fly.

---

The subject of CPU vs. GPU rendering if you take it beyond the usual marketing rubbish is a bit more complex. When choosing the right tool one needs to be aware of what one is rendering. If you render opaque objects that are lit by large light sources then the usual path tracing is fine and that can be done easily on a GPU. Most demos I've ever seen are done like that. If you want subsurface scattering, caustics and dispersion, the the brute force path tracing fails and other algorithm do this better.

Once you get to bidirectional path tracing with metropolis light transport the algorithms and memory requirements are too big to fit into the small GPU kernels and you are back to the CPU.

Sometimes you get to these limitations rather quickly.

---

Also it would be interesting to know that rendering software makers prefer CPU or GPU or hybrid approach, for their products due to various reasons.

Regards,

Anand

[HughesTooling]

This post might be of interest.

http://forums.autodesk.com/t5/design-validate-document/yellow-warning-on-component-with-no-features-...