Multi-Core Support | Multi-Thread Processing

[mspatz]

Revise the base AutoCAD code to support multi-core processors for ALL operations - not just redraw, regen, and rendering.  It is almost impossible to buy a single core CPU anymore and quad core is becoming the standard.  Therefore with a 2GHz processors you only have a 500MHz CPU when running CAD.  This is equivalent to CAD performance in 1995 (20-yrs ago!).

I understand it is a ton of work to re-code, however, it would give MASSIVE performance increases across all the verticals; including Civil 3D.

[mickreynolds]

It would be great if Civil 3D was a true 64-bit program that shared the workload through multiple hyper-threaded processors, instead of being a 32-bit program using only one of my processors, that is 64-bit compatible.  I can create a fairly simple corridor that is a few thousand feet long, but would never think of looking at it in the Object viewer or in 3D, because I run the risk of crashing my computer or the graphics would be choppy.  As it stands now, I have to build the surface from my corridor then view it in the Object Viewer or 3D.  My computer has the performance capabilities to spin a 200 million point pointcloud like it's nothing in third party software that is 64-bit, but suffers mightily when trying to view a 1500 ft. corridor in Civil 3D.

While having 64-bit programming behind Civil 3D in the past would have been helpful, I find it almost a necessity now that we can work on pointclouds, incorporate HD images and photogrammetry, and share data across platforms such as Infraworks and Revit, not to mention we are incorporating a lot of heavy GIS data as well.

[Civil3DReminders_com]

The request you want to make is for Civil 3D to be a multi-threaded application. Using the current structure Civil 3D will need to have AutoCAD become a multi-threaded application as well. If you search for multi-thread and AutoCAD you might find some BS excuses about why Autodesk hasn't done this yet.

Civil 3D is a fully 64-bit program, it uses the full 64-bit address size when going through the processor. Since it is not a multithreaded application it only uses one of the 64-bit processors.

For the object viewer, the performance improvement would be through the graphics card via GPU processing, which doesn't really use the processor as much. I was really impressed with the NVIDIA performance of the Quadro P2000 that turned a choppy slow user experience into one that was decent.

Not sure if you'd be able to modify the title of your request to match the required terminology required to make the request you want a reality.

[awkeller88]

The multi threading Idea is right up there at the top already. Give it a vote.

https://forums.autodesk.com/t5/autocad-civil-3d-ideas/multi-core-support-multi-thread-processing/idi...

There is a thread here that may help with your crashing problems. Check out -GRAPHICSCONFIG command.

https://forums.autodesk.com/t5/autocad-civil-3d-forum/2015-civil-3d-crashes-during-orbit-and-pan/m-p...

~Andy

[mickreynolds]

I am obviously not as learned about much of the discussion in the previous posts, but I do have a questions.  If the problems with multicore support is an issue of moving or redefining (if I understand correctly) records of many independent objects simultaneously, why is it that my third party software I use to register and manipulate pointclouds doesn't have lag issues?  I have a 300 million point pointcloud, whose file is upwards of 6gb, and I can flip and move it around in that space with no problems at all.

Just to be clear, this is an honest inquiry and not a smart aleck post design to elicit ire.  If you can help educate me or improve my understanding of this topic, I would be most grateful.

[piermattei]

My calculator will be faster, by the time autocad update to Multicore! 15 Hhz drafting here we come

[piermattei]

PINNED OUT FOR DAYS

[piermattei]

STILL PINNED OUT

[Anonymous]

I must say that I am quite surprised and disappointed at the same time to find out that my gaming computer that has exponentially more computing power than the manufacturers recommendations is still operating on 20yr old technology.

In my opinion, this shouldn't even be a topic for discussion and is a lack keeping up with industry standards. I pay a lot of money for this software package and I feel that the technology and re-investment into the software should reflect that. 

[BlackBox_]

Perhaps it would be prudent to better understand Speedup.

Multi-threading isn't a magic wand and doesn't actually apply to everything inside CAD... It can and *should* be used for some very specific tasks that are 'Delightfully Parallel', but Autodesk has elected to just not, which is the bigger issue... Converting 30+ year old AutoCAD code to now work with parallelism wouldn't exactly be easy to do either.

CAD is primarily single-threaded because there is an inherent 'cost' to parallelism - the dividing up of work, doing the work simultaneously using multiple CPU cores/threads, and finally re-combining that work (in or not in original sequence's order) - that often makes for no increase, if not a decrease in productivity as compared to simply evaluating the same work in series (one-at-a-time). That is why most multi-threaded apps work with very large data sets (like Point Clouds, rendering 33+ Frames Per Second of video, etc), as that is typically the only time Speedup is advantageous.

Most of the tasks that are 'Delightfully Parallel' can be done in parallel now, using Core Console which was introduced back in 2014 (2015 version)... Autodesk just didn't really integrate that into the main application for such tasks, which demonstrates how much they care about their customer's efficiency & productivity (spoilers: look at their decisions; they don't).

As example:

The PUBLISH Command (even when Publishing in the background) takes an egregious +/- 16 seconds per drawing to processes those drawings in series (one-at-a-time), but I can roll my own Windows Shell menu to leverage Core Console for printing them in parallel and yield +/- 4 seconds per drawing.

Here are some numbers from over a year ago, before some minor workstation upgrades (that helped me get those per drawing times down even lower):

#Autodeskruption

[khaledCULN8]

Hi,

as you know, Civil 3D only utilities one of the eight cores of the CPU.

it is such a shame when you work with a very large corridor, and only 14% of CPU power is being used.

I think there should be an option to modify of how much cores Civil 3D uses.

that would change nothing for those who works with regular CPU, but would make a huge difference for those who work with heavy corridors and have a powerful CPU.

Khaled

[retaveras]

This is true, I do not understand why there is no option to use all cores to capacity, since in high precision and large designs you would have a better workflow.

[Anonymous]

That would entail re-writing Civil 3D core as multi-processing application, which most software companies are staying away from as it is a very labour intensive and expensive task.  As much as I would like to see this as well, "not in my lifetime" is what will probably happen.

Here's a good explanation why it is so difficult:

https://medium.com/@urban_institute/using-multiprocessing-to-make-python-code-faster-23ea5ef996ba

[mattwhite6085]

From what i have been told by several members of the Autodesk team, and i agree with the logic that C3D is a linear process.  Simplified this translates as A+B=C and now we have to add C+D to get E.

in clock cycle terms,

1) Place A in memory

2) Place B in memory

3) Calculate A+B

4) Store Result (C) in memory

5) Place D in memory

6) Calculate C+D

7) Store E in memory

OR multithreaded:

1) Place A in memory

2) Place B in memory

3) Calculate A+B

4) Store Result (C) in memory

5) move C to other thread

6) Place D in memory

7) Calculate C+D

😎 Store E in memory

In this example, its only 1 additional step, but if this has to happen 5000x, you've lost an entire second on a processor clocked at 5GHz .  Do this 60x an hour . . . you lose a minute, and eventually it becomes a real delay.

[JamesMaeding]

@Anonymous 

Yah, people do not realize what they are asking.

@mattwhite6085 

It is exactly a linear process that is not suited for multi-threading. Its only when you get a pool of tasks going that do not interact where you can split to threads.

Having said that, I would bet several parts of civil3d do use multiple processors.

Either way, this idea is way too vague, and I bet the things the OP wants to speed up are not even CPU limited. The things like resolving data references and updating callouts seem to take long, and that is not because the cpu is cranking. Its because C3D is looking around for stuff. The real solution would be to have an external set of data, but also the ability to hook to multiple external sets, so you don't get the old Land Desktop problem of everything in one mush pot.

[CivicDesignDevelopment]

There are absolutely tasks that can be done in multiple threads in a CAD platform. Right off the bat, separation of UI and background calculations. I imagine AutoCAD does this at some levels, but there's clearly other things going on in the UI thread that are thread blocking. It's not an all-or-nothing proposition. You take what can be multithreaded, and multithread it. For example:

• Calculation of volumes can be done in multiple threads, and possibly even on the GPU using CUDA. This would be great for densely defined surfaces. Trapezoidal volumes are summed at the end of the aggregate volume operations. Nothing about that is linear. You shouldn't even have to recalculate the volumes with a refresh button. It should be live updates in a multi-threaded application.
• Building the entire vertex array and assigning graphic shaders can occur not only on separate threads, but completely out of order, as the GPU takes the assigned values at the end and puts them in the layout order on the GPU.
• Viewport rendering can occur independent of other viewports, and from paper space. You'll notice your viewports come in one after another.
• If you put on intersection object snaps, and hover over a TIN surface, it's a blocking operation on the UI thread. Offload object snaps from the UI thread. I can't imagine why this would need to be on a single thread. As soon as a snap is determined, update the state on the UI. I can't even keep intersection snaps activated on any project that has a TIN without manually typing "int" during selection.
• Zooming in and out in AutoCAD is occurring with a new redraw at each interval, loading from memory and apparently involving the file system IO for some reason (???). I don't know why it would need to touch the file IO, but if it truly does, how about making it a separate thread, or at least a task with a cancel token so you can zoom 10 levels down instantly without having to step through each zoom iteration calling through a loop to the hard disk, (which is likely over a LAN, by the way)? This isn't strictly multithreading architecture, but it is multi-threading pattern that applies to single threads as well. It could very well be they are doing this, but the redraw is occurring too late in the stack, and certainly after the hard drive operations. Try zooming over a remote VPN sometime...
• Civil 3D requires that the UI goes to model space to regenerate TIN surfaces. This is a clear case where multithreading on a background task is a perfect solution. If AutoCAD entities are linearly dependent on the UI, this is where AutoCAD really needs a lot of work. I suspect if they are resisting multithread even now in 2020, it's because the code base is backward dependent, and they didn't allow for it to be easily implemented. Not because of some nature of CAD applications, but because the original architecture didn't allow for it. If they're still using codebase from the 90s, you can't really blame them because who'd expect it to not be rewritten a quarter century later?

Pretty much anything that doesn't have some dependencies on other objects can be multithreaded. Obviously there's linear processes going on, but there's no doubt that a lot of blocking operations occur in AutoCAD that don't need to. If this was true, other applications like games with billions of triangles moving in different directions based on physical laws and rendered with much more complex shaders wouldn't be able to exist.

The linear operations are going to happen. There's no doubt about that. But other things don't have to come to a halt. I should still be able to open a menu, switch toolbars, zoom, pan, and maybe even switch layouts or even open another file while it's going on.

[CivicDesignDevelopment]

@Anonymous 

How expensive do you suppose the loss of production among all the users of AutoCAD-based software is?

[JamesMaeding]

@CivicDesignDevelopment 

Now that is an interesting question.

I would say its not that much compared to the problems Civil3D suffers from, and how the dwg format gets contaminated with excess regapps, filters, materials...that jump from dwg to dwg through xref.

There is a laundry list of issues should you want to hear us cry. We ran out of tears a while back though, and now we just whine.

[mattwhite6085]

Wow, your knowledge of how the various pieces could function independently is far beyond me. Careful, Autodesk may offer you a job. 😉

[CivicDesignDevelopment]

If you work in AutoCAD long enough, you become familiar with where it's happening. You know if you click this, and you can't do X, Y, or Z, it's because it's in a single thread. I also do programming, but I was aware of these things years before I started coding. I was on this forum complaining about it 15 years ago at least. Sometimes I come across my old threads, and multithreading is a well-beaten drum.

[ljames]

I'm not too keen on the issues or ramifications being discussed. But I do like interesting conversations, and I am new here. Just the other day while seeking help and reading in a forum, I came across the following... 

Set WHIPTHREAD to 3. Uses additional processor to improve operations such as zoom, redraw or regen.