Multithreading

[rflulling]

Can I get an official, once and for all confirmation from Autodesk: That Fusion360 is still a single threaded application and cannot spawn child processes. That installing more cores to the CPU will not make Fusion360 faster.

Previous research tells me that Electron.exe and Node.js are single thread applications and at this time there is no way to run multiple threads. Fusion360 runs inside Electron, and Electron is dependent on Node.js. This process simplifying deployment over many kinds of hardware and several platforms. But, is also limited to a single thread and cannot spawn child processes. -Only extensions and third party add on generate separate threads.

But the question comes up constantly, can I get better performance from Fusion360 by building a computer with more cores. I tell them: "Based on materials provided by 3rd parties, provided by the developers of Electron and Node.js, and provided by Autodesk, the answer is a resounding: NO. Adding cores will not make it faster and will not improve results." But never mind what was posted a few months ago, and never mind that this is from multiple official sources. Users continue to tell each other that installing a CPU with more cores will get better results.

I literally cannot tell them, it's in their minds, it is an urban myth. That any speed bump is the result of a better per core performance per generation, better bus speed, better cache, maybe even better ram or faster HDD. No one wants to hear any of this. -Bigger is better, more is better, even when it is impossible.

-Though it would be nice to have a way to default force the thread to the least used core in the system. So that it is not also trying to run on the same core as the operating system and other background functions. At the very least force it to core 1 or 2, just not 0.
-Yes we can manually dedicate running code to a core, but is temporary only until that code is relaunched.

[TrippyLighting]

Modeling and timeline computation is mostly single threaded. That is true for almost all parametric CAD applications, not just Fusion 360. Modeling tasks are performed by the geometric modeling kernel. That is the Autodesk Shape Manager or ASM for Fusion 360 and Autodesk Inventor.   The math and algorithms in those kernels don't lend themselves to parallel processing and as such also not to multithreading. 

Also, it must be kept in mind that development of these kernels often started decades before multi core processors were available.

Things are completely different when rendering/raytracing in Fusion 360. That does not involve the geometric modeling kernel and it uses every core available.

Another multithreaded operation is importing STEP files.

[rflulling]

I never expected to learn from posting this topic that Dassault Systems and AutoDesk all but use the same core, forked from ACIS 7.0. But I guess it was a case of seeing who could do better with the same stuff.

Mind you the topic is about Fusion360 factually using only 1 thread. However since learning this several weeks ago, I was and still am rather irritated. In fact nothing I have read about the Kernel even makes mention of their threading strategy.  Back when the Kernel was developed Multicore systems were fairly new, and were also the rage of the industry, with Apple, IBM and Motorola forming the spearhead and Intel desperately trying to catch up. Today, Intel might like you to believe that they invented Multicore CPUs.

What is desperately annoying is the lack of direct usage of multicore. The dependence on the OS to manage the cores. And Windows gets an F grade at doing this. So I really want to see the developers step up.
At this rate Quantum will start being sold and the code will still be single thread. Unless we start having AI write it.

[TrippyLighting]

---

@rflulling wrote:

I never expected to learn from posting this topic that Dassault Systems and AutoDesk all but use the same core, forked from ACIS 7.0. But I guess it was a case of seeing who could do better with the same stuff.

---

Dassault Systems distributes a number of CAD systems, most notably Catia and SolidWorks.

Catia uses it's own proprietary geometric modeling kernel and SolidWorks uses the Parasolid kernel licensed from Siemens.

Autodesk has continued to develop the geometric modeling kernel after the fork.

[MichaelT_123 · Accepted solution]

Hi Fellows,

The internal data structure and organization of the data processing flow in F360 (and its inner kernel) is not conducive to running it in a multithreaded fashion. This legacy software is like a sumo wrestler forced to get seated on a racing horse and win the Melbourne Cup. It will never happen!

I think F360 uses about a single percentage (or less) of the current average hardware capability. There is only one way to get the software on par with modern computing hardware. Re-write, re-structure and re-program it. Obviously, it would be a significant undertaking. Other CAD systems also show symptoms of legacy dementia, … not only F360.

Regarding multithreading, not only would the implementation be complex, but the benefits would not always be significant in many cases, not worth the associated overhead. I believe F360 has done some experiments with implementing a curve offset (try to check it on your CPU Performance Monitor).

Another more straightforward and cost-effective venue would be implementing Advanced Vector Extensions instructions (AVX2,..), speeding up matrix, vector or even simple copying operations hundreds of times. I am not sure if AVXs are in use by the F360 kernel.

The supplementary method, in single-threaded mode, would be unloading small chunks of code to the GPU… without demolishing the whole house but replacing some walls brick by brick (or, in ambitious scenarios, even a kitchen sink)

So far, … you can dream, guys … I am joining!

Regards

MichaelT

[TrippyLighting]

---

@MichaelT_123 wrote:

So far, … you can dream, guys … I am joining!

---

Ultimately, I believe this will happen, but that development is not going to come form the established players in the CAD market. It will most likely come out of the academic field!

Universities have the luxury to spend students time for free on thesis and research papers. Once the "product" has reached a certain stage and industry starts paying attention, a startup is created and just a few years down the road the new venture is sold to Autodesk or Dassault Systems.

Then development will slow down drastically to glacial speed.

That's the usual tech entrepreneur game here in the US at least 😉  

[rflulling]

Maybe after I crash Fusion360 hosted on the server enough times they might start to notice. Gee, our users really are running the program way harder than single thread can keep up. I mean, who likes to wait while the program appears to be crashed, as it literally just can't do the math needed to model anything on the screen. So everything goes black and white. Windows pops up a message asking if you want to close the program and the pinwheel just keeps spinning.

For Fusion Online, it's a double threat because you have to open, close or save within a fixed time limit or it tries to close the session. But in some cases where Fusion actually crashed, it is not hard to figure it out when the window is still stuck even after the session ending notice which generally reset the window.

Make a coil, convert it to a spiral. Make it complicated, get a crash. Make it thin, get a crash, make it so it has many layers get a crash. So you survived making a spiral with 100 layers, with a 2mm gap and 0.11mm wall. Now try to stretch one side so that it looks like rolled up paper. Anything over 10mm is more than fusion can handle and it will not recover even on the server. Hard Crash. -Found this out while trying to replicate a spool of materials my employer produces. But alas it seems this simply cannot be replicated in Fusion360.

[Phil.E]

Hi, if you have a crash report number I'm glad to look into what's going on.

[rflulling]

---

The internal data structure and organization of the data processing flow in F360 (and its inner kernel) is not conducive to running it in a multithreaded fashion. This legacy software is like a sumo wrestler forced to get seated on a racing horse and win the Melbourne Cup. It will never happen!

I think F360 uses about a single percentage (or less) of the current average hardware capability. There is only one way to get the software on par with modern computing hardware. Re-write, re-structure and re-program it. Obviously, it would be a significant undertaking. Other CAD systems also show symptoms of legacy dementia, … not only F360.

---

The ultimate goal was a solid Yay or Nay from Admin. There are certain folks, online Facebook and Reddit who for reasons I think are more deeply rooted in personal opinion or mythos. Like Wives tales of old, they are convinced that the program is Multicore and installing a more current CPU with more cores will make everything better. Even after being provided links to Electron, Node and Java, they still wont accept. Infact I think arguing it has nearly gotten me banned from a few groups, since their admin had decided "I was wrong." Since the Official posts from Autodesk which did state that it was single threaded, were now several years old, and well, it's been updated many times since then...

[rflulling]

---

@Phil.E wrote:

Hi, if you have a crash report number I'm glad to look into what's going on.

---

To be fair that is the fastest reply from Autodesk I have ever seen! No report number that is not being shown on my side.

Since the crashes are happening in the server I would think it should be easier to find, but then, since the crash is happening in Java, I am not sure were its actually getting stuck and crashing, only that it is. When it dies in Windows, it some times just vanishes after being stuck. Online, it just gets stuck and the message from windows asking to close the program is the only error message.

[rflulling]

---

Regarding multithreading, not only would the implementation be complex, but the benefits would not always be significant in many cases, not worth the associated overhead. I believe F360 has done some experiments with implementing a curve offset (try to check it on your CPU Performance Monitor).

Another more straightforward and cost-effective venue would be implementing Advanced Vector Extensions instructions (AVX2,..), speeding up matrix, vector or even simple copying operations hundreds of times. I am not sure if AVXs are in use by the F360 kernel.

The supplementary method, in single-threaded mode, would be unloading small chunks of code to the GPU… without demolishing the whole house but replacing some walls brick by brick (or, in ambitious scenarios, even a kitchen sink)

I know they have for sure improved stability in several places and the load on the CPU is vastly improved from when i started, back when it was free to hobby and there was no file or object limits.

I suspect given how it's built at this time the only simple solution is to start over and I don't seen that happening, any more than I forsee Dassault offering to sell a more recent version of their own 3D core.

[rflulling]

---

@Phil.E wrote:

Hi, if you have a crash report number I'm glad to look into what's going on.

---

Just remember this post when you hear the server that manages online access has crashed. I swear I am not Trying to crash the server. But Fusion is getting overloaded by simple requests to do things it really doesn't want to do, and as a result its locked up. Even now.

[Phil.E]

Thanks for the explanation. I can try to replicate the problem more easily if you have a file I can use for testing. If you can provide a share-link via pm I'll check it out using Fusion online.

[samiris.coral]

There's no excuse to block the main thread while computing and make the program unresponsive (and often crash). The correct approach would be to separate all the computation from the UI thread, showing a loading indicator while doing the computation in a new process, and preferably let the user cancel an operation if it's hanging (kill the spun process). This is just bad programming practice and kind of inexcusable from Autodesk who charges a premium for their products.