People talk about speed in design software like CAD. They talk about cores and threads and GPUs. All of that helps, but precision sits at the center. If the math slips, the whole thing falls apart. AutoCAD has pushed for more precision since the eighties. Jon Walker showed this with his old solar system drawing. It mapped the universe to scale. You could zoom from the planets down to the tiny plaque on the lunar lander. The file still opens today.

Download the Solar DWG file for AutoCAD Download SOLAR from ACAD2-18-updated
The drawing shows how floating point limits work. When geometry sits 149 million units from 0,0, you start to hit the ceiling of a floating point number. You only get so many digits. If most of those digits describe the distance to the origin, you do not have many left for tiny arcs or offsets.
To show this, I drew a small polyline with a bulge next to the lander plaque. Then I offset it by a tiny amount. The arc collapsed. The bulge rounded into nothing. The polyline was fine. The system simply ran out of precision while trying to hold both the huge coordinates and the small radius.
I moved the same geometry to 0,0 and tried again. This time it worked. Nothing changed about the geometry. The math just had more room to breathe. AutoCAD has used every bit of floating point precision available since the beginning unlike some other CAD like MicroStation that used a drawing based precision. The limits show up only in extreme cases, but they still matter.
AutoCAD gives you a clean and predictable precision model that behaves consistently from one version to the next. MicroStation gives you more knobs and internal scaling that let you stretch the model space in different ways. Both have strengths. Both have limits. The trick is knowing where the edge is so you can avoid surprises.
This leads to another question.
If multi core processors are everywhere, why does AutoCAD and Civil 3D not run every operation on every core.
Some operations do not split cleanly across threads. Some depend on strict order. One step must be finished before the next begins. If you try to scatter that across cores, you break the logic.
Some operations touch the DWG file or other referenced files. Reading and writing must be controlled. You can parallelize small parts of it, but you need locking and coordination to keep the file safe. That overhead often costs more time than it saves.
Some operations modify shared geometry. If two threads update the same thing at once, you risk corrupting the drawing. Locking prevents that, but locking slows everything down.
Some operations rely on floating point results being identical every time. Running them across threads can shift instruction order. That creates tiny differences. Those differences grow and change the geometry. CAD software cannot allow that.
There is another layer to this. Some operations run so fast that parallelizing them would gain almost nothing. You might shave off a fraction of a millisecond. The user never sees that. What the user does see is a defect introduced by rushing into multithreading just because the hardware allows it.
There is also the history of the code. CAD systems have deep areas built by CAD and graphics software legends. The work is complex and battle tested. It runs fast and predictably. Refactoring those areas to spread tasks across multiple cores is not simple. It risks regressions and defects that take teams cycles to unwind. The tradeoff does not always land in the user’s favor.
AutoCAD is multi threaded where it makes sense, for the moist part. Graphics, Rendering (look at the realtime swatches of every core as you render) Plotting. Save compression. Some regeneration tasks, some text, and others. The parts that rely on exact shared geometry and predictable math stay single threaded because correctness matters more than chasing peak core usage.
Hardware will keep improving. Multi core systems will keep growing. I’m sure Autodesk continues to look for places where threading helps without hurting reliability. But the limits are real. Precision has a cost. Parallel math has a cost. The job is to pick the tradeoffs that keep drawings stable and users productive.



