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.

[Simon_Blain]

Just fyi, a 2GHz with 4 cores is 4 x 2000 not 2000 / 4

All 4 cores work at 2 GHz

But the point is still fully justified, multi-core as been around for a long time now, Autocad should use all of them all the time

[dgorsman]

Multi-threading isn't a magic wand, its not that easy to implement, and won't give as much "MASSIVE performance increases" as some would think.  Given that AutoCAD is rarely the only application running I'd rather it not hog all the cores. 

There can only be one process modifying one data record (drawing is a database) at a time, otherwise the results are not predictable which is a Bad Thing in computing.  And with heavily data-driven programs like Civil3D the order of change becomes important, you can't have something change data A after its been read to make changes for data B; otherwise the state of data B no longer reflects the actual state of data A.  That kind of dependency doesn't lend itself well to parallel processing.

The best comparison is for image processing and rendering.  Each pixel in an image is fully independent of all the others, so every one of them can be processed in its own thread without affecting the others.  With a little organization, iterative processing can be done on the image without having to wait for the entire image to finish processing at each stage.

Some others had the idea of unloading the UI elements to their own processes, which might not be a bad starting place.  The same problems still apply, even in a read-only use ie. they would still need to wait until changes are complete before updating the displayed values.  They could constantly monitor for changes.

[mspatz]

I would say going from having ~8 GHz available vs. 2 GHz (with my corrected mistake in numbers) would be significant.  Just because it is hard, doesn't mean it is not worth it.  Hard things are typically most worthwhile.  I understand the complication of one process modifying one data record at a time, but let's be creative and think outside the box.  Maybe how AutoCAD stores data in the record needs to be modified?

One huge area that needs a CPU performance boots is simply opening a drawing.  There is no writing of data in that operation?  I'm not a computer engineer so I look to the experts to come up with solutions.

Another idea: the core application should open in a thread and then could each drawing opened in it's own thread?  Right now, you have to open multiple Civil 3D's to have that equivalent.  If each could be it's own thread, while you are waiting for something in one drawing, you could pop over to another without CAD graying out.

CAD hogging the entire CPU can be restricted by Affinity if desired.  Many hard core users only have two applications open at a time; CAD and Outlook.

[mspatz]

Plus, if one drawing would crash, it wouldn't crash them all?

[dgorsman]

Processor speeds don't work that way; its like adding speeds of individual vehicles together.  Think of it more in terms of total operations needed to complete a given task.

When I mention "hard to do", I'm referring to the juggling of getting everything separated out and then connected back together, and doing so in a way that saves time over simply doing things sequentially.  Its not always worthwhile.  Have a read: https://en.wikipedia.org/wiki/Parallel_computing

You bring up a good example: opening a drawing.  Its read from storage into memory.  That's a linear operation; you could have 50 "readers" connected to the same file but they would all be running through the same data at the same time, giving no gains.  In order for that to work across multiple processes there needs to be the ability to skip ahead in an organized fashion.  That also assumes as data is read into memory any required dependencies already exist.  For example, every entity has a layer, so as each is read the layer must already exist (consider entities with BYLAYER properties).  Alright, lets load the layers first; layers have linetypes (and plot styles, for STB files) so those must be loaded first.  Now we've got a lot of supposedly parallel operations waiting on others to finish - effectively back to sequential processing but with a lot more work.

A lot of this doesn't require any specialized engineering or math knowledge.  You just need to break down operations into logical steps and think each one through.  What is required to complete this step?  What other steps can be completed regardless of what the status of this one?  And so forth.

[Dexterel]

Rebuilding a corridor: each section is independent an can be process separately. When rebuilding a corridor I expect to use all my cores to do so. Or rebuild multiple objects that are not interdependent at once (a corridor and a surface or multiple corridors simultaneous).

[joantopo]

In my opinion, multi-core would be useful to compute all corridors.

Nowadays, Civil 3D gets internally an objectID collection of the corridors with the properly order they must be processed according to the priority.

For example, if the corridor B is dependent of the corridor A, corridor A must be computed the first one.

But if you have an isolate corridor, (it doesn'have dependencies or other corridors need it), then another core could compute exclusively that corridor.

I agree with the fact to write the database because you can't writing to the database at the time.

Maybe, the data calculated of the corridor could be saved in a buffer and finally write the database.

[peterfunkautodesk]

A few comments on this one...

1. While AutoCAD and Civil 3D don't take full advantage of multi-core processors, the processor speeds listed above aren't totally accurate. For example: in my machine I've got a Intel i7 - 4900MQ processor that runs at 2.8 GHz. However, it is a Turbo Boost that allows a single core to run at 3.8 GHz. It does this by shutting down un-used cores and allowing the remaining cores to run faster by drawing more power and generating more heat.

2. Multi-threading Civil 3D would be very, very hard to do and at the end may not have that great of impact on the speed. 

We'll keep this as Under Review, but we're focused on other ways to speed up your workflows.

Regards,

Peter Funk

Sr. Product Manager

Autodesk, Inc.

[mspatz]

Folks: Off topic, but if you have not implemented this fix check it out. It is making a HUGE difference for us in performance increases. https://knowledge.autodesk.com/support/autocad-civil-3d/troubleshooting/caas/sfdcarticles/sfdcarticl... Autodesk: consider making this Hot Fix more visible. It is a big deal - for v2014 at least.

[balenger.c]

Here is an offshoot of the idea above. 

What about giving and option to kill 1 drawing in the session.  I understand the difficulty in bringing Multi-threading to CAD, but being able to control/organize how CAD is running would be very useful for dealing with buggy or old files.  

In the metaphor above, (data - viewer example) killing 1 viewer and maintaining the others without aborting the whole session should be relatively easily?? 

if there is new or orphaned data in the old file that has caused the crash then that can just generate a backup and you could deal with the dependencies manually. 

[CyrusLSteele]

I work with aerial imagery quite often, a simple coordinate transformation from the mr sid, to my drawing coordinate system is ridiculously long. Coordinate transformation every point is independant of the other, this should use as much power as possible. In reality it is throttled to a single thread. While time for coffee, this system will be using one 8th of it's power and a little over 1/4 of it's ram to process one image for the next 30 minutes.

[Frédéric.SERIN]

Distribute calculations of all Civil3D objects to all the CPU cores : corridor regions, frequencies, sample lines, section objects, etc...

[BlackBox_]

A thousand times over... This.

AutoCAD team is in maintenance mode now for several years, only offering low hanging fruit 'features' each year, and this inherently holds back all vertical products; methinks it unlikely that the Civil 3D team will roll their own multi-CPU core adaptation without vanilla AutoCAD support.

I understand that most selection set processing is done sequentially (series) - you're smart people (Autodesk plural), either figure out how to [thread] safely do same in parallel, so we can all benefit from modern workstations (instead of overpaying for single-processor core dependent apps), or acquire a company that can do it for you. 

Please, for the love of all that was once good about Autodesk... Please, stop holding us back.

[sebastien.gagnon]

No need to comment. Please make ALL new software multi-thread. Thanks. 

[dgorsman]

@BlackBox_ You've dug pretty deep into the data/calculation side of things - could you at least get them started by pointing out some things that could be calculated in parallel, without taking into account things like the DWG database structure?

[BlackBox_]

@dgorsman, my friend - the elegance with which you’ve crafted that post is truly a gift - one that I admire, and struggle to replicate. :beer:

---

Okay, let's get a few disclaimers out of the way:

First, I don't claim to know everything, but what little I know, I know well.  Second, I expect a continual up-hill battle for actually achieving a stable, multi-threaded (thread safe) AutoCAD + verticals.  Tertiary, methinks there will be an evolution of DWG database format required (even if only in part), or at minimum an evolution to how AutoCAD products handle a database derived from DWG (copy of database in memory, not the actual DWG file).  Quaternary, multi-threading is not an end-all solution, and should only be implemented for specific, data heavy processing tasks (aka right tool for the job).

---

That said, let's consider a few common tasks that are ridiculously slow, perhaps why, and what might be done to improve them:

Batch plotting/publishing sheets – 

Don’t even get me started on the difference in plotting (yes, even Civil 3D drawings) from vanilla AutoCAD to plotting in Civil 3D natively; it’s like the recent Alabama (AutoCAD) vs Vanderbilt (Civil 3D) game, no contest (sorry Vandy). Haha

How old is Core Console at this point, and we can’t successfully batch plot a plan set (or selection thereof) in the background, in parallel (not series), without each rolling our own Script to call Core Console and plot, along with the missing Windows Shell context menu to make it a select + right click operation from File Explorer?

Example: http://forums.augi.com/showthread.php?168897-Update-titleblock-lisp-AutoCad-2017&p=1327141&viewfull=...

Why is plotting/publishing so slow?  Put simply, because drawings are printed sequentially (series) one-at-a-time, the same way they were back in AutoCAD 2000 on Windows XP x86 (I know, my surveyor still uses this daily). 

There’s been no concerted effort to actually improve plotting beyond minor driver adaptations since +/- 2009 version which introduced PUBLISHCOLLATE sysvar, and Autopublish mechanism.  Given the advent, and wide-spread adoption of 4+ core CPU workstations, this is pretty pathetic.  To boot, Autodesk doesn’t distinguish between exhibit/sheet drawings (for plot), and model drawings (DREF/XREF only).

Autodesk suffers plot/publish schizophrenia; Plot, Publish (Command & SSM), BatchPlot, PDFExport, Plot via Core Console, and my personal favorite, Autopublish.  The latter is the single, simplest & fastest way to produce a PDF of your sheet drawings.  Period.  It also doesn’t help that Autodesk has hard-coded use for their PDF-related drivers, even if your named page setup specifies DWG to PDF (linky), acknowledges doing so, and then never follows through to fix it. Grrr

https://forums.autodesk.com/t5/autocad-forum/2016-dwg-to-pdf/td-p/5972426

I would love to see a native enhancement to Publish, accessible via Command or SSM context menu, that utilizes Core Console to plot drawings in the first true background processing implementation. 

One that supports the active Profile used to initiate the procedure – currently, Civil 3D users must duplicate work to configure the vanilla AutoCAD Profile’s settings to plot the same as their production Profile in Civil 3D (learned that one the hard way, not documented anywhere! Grrr) – and support a new pseudo-named MAXPLOTCORES sysvar which will only consume N number of new threads (Core Console processes, so users can suite their workstation specs), and run as many ‘rounds’ of Publishing in parallel as needed to complete the requested plot job.

---

Selecting COGO Points – 

Go ahead, open Properties Pane, then right click a Point Group and select the associated COGO Points… Watch how long Properties Pane takes to ‘finish’ your selection of said COGO Points (translation: iterate the selection set, read & populate the appropriate Properties, or just say Varies)… Now <Esc> to clear your selection, close Properties Pane, and perform the same selection of the COGO Points; significantly better ain’t it?  Spoilers: yep.

This is just one of many instances where Civil 3D (and ultimately AutoCAD) simply fails.  Autodesk designed the framework on which everything inside AutoCAD is created, persistently stored (saved), and performs while open. 

If there’s a performance flaw with how this basic, repeated procedure is completed, it’s their own doing – more specifically, what worked then (circa WinXPx86 and older) is not the best use of technology today, and incumbent upon them to constantly review for missed opportunities for performance gains.

---

Importing a Point Cloud –

Once one of the best features of Civil 3D (IMO), now stripped away for us to add multiple steps through [ReCrappy], and you may not even be able to download a Surface format that Civil 3D can use without cloudy credits.  The person who authorized this idiotic move should be Leroy Jethro Gibbs slapped across the back of the head, and recorded to be put up on YouTube for endless viewing.

I get it, Autodesk needs to drive traffic, so they intentionally close the door to native Point Cloud import using Civil 3D (translation: gives all users the middle finger, and says I don’t care about your productivity) – you’d think someone, anyone at Autodesk in authority would have looked at this and said ‘this is dumb, guys, users are going to be pissed; why don’t we replace the native functionality with the ability for Civil 3D to call ReCap silently to yield the same native effect for users, whilst leveraging our new schmancy tool in a separate thread then import that file as if they never left Civil 3D?’

But, noooooooooooo... Not a soul at Autodesk has (publicly) suggested such consideration.

---

Rebuilding a Corridor/Surface – 

Subdividing a single, moderately-sized project into myriad Corridors/Surfaces is a ridiculous complexity of work that I don’t have time (nor patience) for – extremely large, or long projects there’s simply no other way to still have manageable file sizes, with decent drawing performance – Instead, I prefer to make money by getting work out of the office and collecting that fee.

Given that even for a _NoDisplay Corridor, or Surface Style, these Objects are ‘rendered’ to generate sections, contours, etc. there’s simply no excuse for why we’re not seeing similar performance to that of Infraworks, especially for those using Infrastructure Design Suite or AEC Collection.

Now, I am not as familiar with the distinct mechanism responsible for Infraworks’ speed at this task, but I do have a reasonable degree of confidence that it is something that can be either integrated into Civil 3D natively, or perhaps called silently from same in the background (once AutoCAD is thread safe) and merely ‘displayed’ in the Editor using a local disc service (to handle the repeated calculations in another/multiple thread[s], similar to how Land Desktop was really fast at all times and only slowed when querying external database), until the drawing is being saved at which point it should be saved in the drawing as a Block (making it faster to open next time, until one or more dependencies are modified).

Also, ObjectModified event handler should preclude changes to dependency Color – No, changing the Alignment color should not cause the Corridor to go out of date, or automagically rebuild.  Stares at Autodesk, and blinks.

Why is the lack of multi-threading such a nerve for me? 

That’s easy, I just procured all new workstations, and am disappointed that there’s so few options for workstations for single-core dependent apps – that, and I hated spending money on inferior hardware that my primary design tool cannot even fully utilize – practically everything high-end is now pushing 6+ CPU Cores, or 2+ CPUs, and Autodesk has done didley squat to make AutoCAD (one of the few actual products they developed, and didn’t acquire) able to leverage a modern worksation.

On the topic of AutoCAD performance, the AutoCAD team has little need or desire to actually improve anything.  Need proof?  Just look at the ‘new features’ for the last handful of versions released, or join the Betas and waste your time trying to convincing them to stop asking you to ‘paint the front door, again’ as an Autodesk employee analogized to me by phone last year (not subject to NDA).

The single, most cost-effective ($300) way to improve Civil 3D performance is to make your boot drive a Samsung 960 PRO NVMe/M.2 SSD, and configure your profile to utilize local disk for XREFs, etc.  If you can afford it & your motherboard supports dual M.2 slots, get two and run them in RAID 0.

Now, we’ve seen a significant increase in productivity with our new workstations, but they’re also basically maxed out, with no real room to upgrade later, which means we’re going to replace them at that time (less value for the investment over time)… So it’s a good thing I got them at +/- 47% discount! Haha

My specs:  Dell Precision T3620, Win10x64 Enterprise 1703, Intel Core i7-7700K 4.2 Ghz (w/Turbo), 512 GB Samsung 960 PRO NVMe/M.2 SSD, 32 GB DDR4 RAM, 8 GB NVIDIA Quadro P4000 GPU.

---

If you’ve made it to this point, you must be really be bored, or just not have something better to do; good for you!  Frosty brews are my treat if you venture to SW Florida.  Haha

Cheers

[Frédéric.SERIN]

Vote here too !

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

[BlackBox_]

@peterfunkautodesk - Please also see this thread:

https://forums.autodesk.com/t5/autocad-civil-3d-ideas/distribute-calculations-to-all-the-cpu-cores/i...

@CyrusLSteele - Not sure if this helps, or not, but I've found a significant increase in Civil 3D performance by setting Page File to 2x RAM, and MAPIOPTIONS Command, Memory tab, set temp file location on fastest local drive (ideally a Samsung 960 PRO NVMe/M.2 SSD), and set Memory limit to 75% RAM.  Also, set WHIPTHREAD == 3, XLOADCTL == 2.

https://knowledge.autodesk.com/support/autocad-civil-3d/learn-explore/caas/CloudHelp/cloudhelp/2017/...

http://docs.autodesk.com/CIV3D/2014/ENG/index.html?url=filesMAPC3D/GUID-20BF92B5-C1D0-4BE2-8E80-7CEE...

Cheers

[dgorsman]

Pretty much agreed with everything there, although to be fair cloud credits are only for the online targetless registration.  I do like the move into ReCap as it centralizes the point cloud handling into one dev team rather than very spotty implementation across various products (not at all in Inventor or AutoCAD, good in Civil3D, mediocre in Navisworks).  As you say though, should still have left the tools in place and have them operate on the nicely indexed ReCap contents.

And if you're looking to get away from hurricane season, swing by for Stampede, k-country, and dinosaurs.  Oh, and beer too. 

[BlackBox_]

That is an impressive level of agreement, especially given all that I posted, and on such a topic where I know the extent to which you've gone to manage expectations in other threads... For that I thank you, @dgorsman.  :beer:

We agree that the mutually beneficial solution (re: Point Clouds), is for Autodesk to implement sufficient silent switches in apps like ReCap, that Civil 3D can still 'import natively' albeit through using ReCap as a background service.  I acknowledge that Autodesk will attempt to only offer this would-be mechanism for Suite/Collection licences, or for those with both a subscription/license for Civil 3D and ReCap individually.  Such is the nature of the times. 

To your last - I appreciate your offer! We stayed in town for Irma, which passed just 30 Miles East of us, and we're good to go after power was restored.  Not sure if we'll venture that far North anytime soon; Mrs. BB has made it quite clear that pretty much anything North of the Mason-Dixon line (and even most places South of it, but North of us) is a frigid hell compared to SW Florida, and we should only ever go somewhere warmer (it's hard to disagree with her, especially in a bikini).  Haha

Cheers