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.

[JamesMaeding]

@ljames 

interesting, its only two processors that get used. Normally the jump from one to many does not get limited to just one additional.

[joantopo]

This is the main reason why people is changing to OpenRoads Designer. PERFORMANCE!

[Anonymous]

I would just be happy if I could run multiple copies at the same time on different cores.

[AllenJessup]

https://forums.autodesk.com/t5/autocad-forum/multicore-processors-more-2-cores/m-p/9044527#M994373

They're still playing with it.

[TimYarris]

Both the Civil 3D and AutoCAD development teams have research initiatives underway. These initiatives relate to using multiple cores to speed up specific operations. While it is not on the roadmap to do a wholesale rewrite of AutoCAD and Civil 3D to support multi-core processing for the entire product, we have identified areas where using multiple cores will increase performance significantly.

We'll be able to share more details in the coming months.

[JamesMaeding]

@TimYarris 

Thanks, but the people who have followed adesk for years and have programming backgrounds are wondering what "accepted" even means anymore. There has never been a lack of technical talent at adesk, but more of an organizational problem.

The question is "who decides what to do?" ever plagues things, and we see it from the outside. I even feel bad for the technical adesk people, it must be frustrating. So we appreciate the "accepted" status, but unless there is some noticeable effort to reach out to the really experienced programmers and cad managers out there, it worries me a bit. Its not an easy task, it will need long term testing, and planning where you get the spec in order before programming it and realizing the foundational concepts were not quite right. It will be interesting to see what actually happens.

[TimYarris]

Hi @JamesMaeding ,

I understand your skepticism and we're trying to do better. Here are some comments on your feedback:

• Regarding the "Accepted" status: I'm applying this status to ideas that the development team is actively working on. In the multi-thread processing case (as I mentioned), both the Civil 3D and AutoCAD teams are working on areas in which they might support multi-thread processing. I'm afraid I can't get into specific details on a public forum, but we are working on this area.
• On reaching out to customers, programmers, CAD managers: We absolutely are doing this -- especially as we work on improving performance and filling gaps in the Civil 3D API. We regularly post calls for feedback to our Infrastructure Futures community and speak to customers of all sizes. If you'd be interested in offering feedback on performance, please reach out to me at tim.yarris@autodesk.com and I can facilitate a chat with our development team.
• On "who decides what to to": This is a process that is part art, part science. We balance our priorities across a number of areas, primarily direct customer issues/wishes and strategic priorities. I'm considering doing an AU session on this topic, as customers bring this up frequently.

[piermattei]

I assume the IOS version of ACAD supports multithreading.  Therefore, I assume this base code will be ported to PC and C3D will be intergrated into this code. 

[JamesMaeding]

@piermattei 

Since the mac version of acad is substandard, don't even bother with it. Get Bricscad if you really need to use a mac, it has civil3d object enablers you know. Really though, if you are doing cad for a career, you need to be on a PC, not that they are superior, they just have all the functionality you will want for 3rd party apps.

[Beka_Tchigladze]

lady's and gentlemen's  it is already 2021, this idea as it was declared is 5 years old but, it was long ago when human produce first multi core processor but, my civil 3d is modeling corridor with just one core can you imagine with one core. I have tried with my 10th Gen Intel 8-Core i7-10870H Upto 5.0 GHz processor today to model corridor and create Cross sections, it took just 12.5% max for processing and modeling, also from 50% to 60% of ram. The question is why? If there is the case when you have small site to develop or short road corridor it is really fast modeler but when you have several km's of road and you need thousands of cross sections it is impossible to work for even small changes it needs ages to rebuild everything. I don't know how to deal with the software. 

[JamesMaeding]

@Beka_Tchigladze 

Given that Autodesk does not invest in Civil3D any more, that answers part of it.

You need to chop up your project a bit as the software can only handle so much as is.

There is another issue though - processes that depend on each other cannot be run in parallel.

So you would have to have a decent level of detailed knowledge of how civil3d does things, to say if this or that should be run in parallel.

The civil engineering industry needs to stop looking to civil3d for the future.

It does many good things but fails in key areas like lightweight data sharing, slow speed from object chat, hub and spoke structure utilities...all critical enough to need other software to do them. Our company solved all that with in-house programs. Its not hard to solve but takes a designer who knows programming working with users to get the core correct. Then the uses are endless, and way simpler than big corridors.

[kidznok]

@JamesMaeding
"Given that Autodesk does not invest in Civil3D any more, that answers part of it."
So I should start working on Infraworks ?

[AllenJessup]

Reports of Civil 3D's death are greatly exaggerated. The Development team is still hard at work. Grading Optimizer, Coordinate Transformation Tool and Geotechnical Modeling are three recent additions to Civil 3D.

Just about anything that can use multi-threading does. Engineering calculations are linear. So can't be split up.

[JamesMaeding]

@kidznok 

Infraworks is one of my favorite programs and I would recommend it. You also should work on your GIS skills using things like QGIS, for dealing with large elevation model files (.tif, .img....) out there.

@AllenJessup 

You know more about the current team than me for sure. I guess my thing is they settled on their data sharing mechanism, and left pipe networks/feature lines as part based (hub and spoke), rather than normal civil engineering horizontal/vert alignment type data where profile PVIS do not line up with plan view segment start/ends. I use civil3d for many things still though, especially surfaces, and maintain our software such that I can convert back and forth with a click. I would argue that adesk has left more on the table than its taken, because of that pipe network and feature line thing. It cripples modeling compared to tools that do that correct.

[Civil3DReminders_com]

@AllenJessup "So can't be split up." That is not true. Many items in Civil 3D could be processed on a different thread. For instance, clicking on a pipe causes the attached structures to be updated, and any pipes attached to those structures to be updated. Clicking on one pipe ends up with at least 3 transactions (I've seen up to 7) being processed. All of that work could be done on a different thread. So when I click the pipe, the data is grabbed from the other thread that has already updated the information to reflect what has changed in the drawing. 

Clicking the Application Button goes through and grabs the file information in the recently used drawings list. That is the pause that is often there for large files on a network. A thread could be run to grab that information and then update the UI thread once the data is collected. Often times I'm not even using that information and we are waiting for no reason other than Autodesk not knowing how to do multi-threading.

Corridor sections don't depend on the section before or after them. The only dependency is creating the corridor feature lines, and that could be done at after processing the corridor sections. 

There are many more instances I can come up with where Civil 3D could be sped up. Don't fall for Autodesk's crappy excuses for not implementing multi-threading. In my own code I've implemented many of these items to speed up my code, there is no excuse for a billion dollar+ company to not learn how to use multi-threading. 

Even InfraWorks doesn't use multi-threading well. It seems the improvement is a spinning wheel of death to let you know the program is processing data that could be done in the background instead of pausing the UI. 

[balenger.c]

I'm sure they are hard at work on those points, but the spirit of this thread and idea is that civil3d needs a decently big quality of life update for the 2020 era.  I don't want new features, I want old (core) features to run smoothly and effortlessly regardless of the size of the file.  When I try to move a featureline and there are ~100 in the drawing I don't want to wait 1-2 seconds, when I build a corridor for a mile of road I don't want to build multiple files for just the grading work, I want the file system to be elegant enough to handle what i'm asking it to do, and I expect the capabilities to increase over time through updates.  Plenty of other industries have software that handles larger more complex data sets without issue.  

It seems that the development team is more interested in new sparkly tools, but ignores the fact that they aren't particularly useful, and rarely save time.  I think most designers can agree that the biggest issue is speed and time saving, second only to stability. 

if the answer as someone else pointed out is for each company to develop their on tools on civil3d, then that is quite the loss for the average civil3d user, and contributes to the 'stability' issue as well.   

[JamesMaeding]

@balenger.c 

Hard at work, but how many of them?

Maybe @AllenJessup  can comment on that, as I think more muti-threading is DOA since adesk is afraid to do architectural level changes to acad, c3d, or anything major.

They can tweak sub-tools, and seem to be doing that, but not major ones from what I am seeing.

I'm limited though, I don't follow adesk as close as others these days.

[AllenJessup]

@JamesMaeding 

Good points. I don't do pipeworks often but my experiences haven't been good. They know about the multi-threading issue and have added to any processes that can benefit. But you can't break up many of the calculations and distribute them across multiple threads.

[JamesMaeding]

@AllenJessup 

I did this article explaining it:

https://www.xyht.com/civiltransportation/the-need-for-civil-bim-level-objects/

I'm not someone with ideas, I have fully implemented them in acad and they solve things better than expected.

Programmers understand the multi-threading issues better than most, as they discover they don't solve much for little things. They absolutely help on larger issues, like splitting 150 million point cloud points into chunks, triangulating, simplifying surface, and adding back together when done. Point clouds are another area adesk has left the whole meal on the table. They have barely taken advantage of them yet.

[AllenJessup]

@JamesMaeding 

Interesting. Thanks for pointing me to that.