“CAD software is single-threaded”: why it's not that simple

Every now and then I hear that today's CAD software is bad because it can't make use of modern processors: "it's single-threaded". The evidence is usually a Task Manager screenshot taken during a rebuild: one core at 100%, the others idle.

The observation is often correct. The conclusion much less so. It ignores three realities: some operations are sequential by nature, parallelizing doesn't always pay off as much as you'd hope, and these applications carry decades of code behind them.

I won't talk about other people's code, which I don't know from the inside. I'll talk about ours: at Wiip, we write the geometric kernel of Cadoscopia 3D, a free application. We have parallelized some parts of it. Others remain sequential, and not for lack of trying.

1. Some operations are sequential by nature

In a parametric modeler, a part is a feature tree: a list of features applied one after the other.

Sketch 1 ──► Extrude ──► Hole ──► Chamfer on the hole's edge
                │
Sketch 2 ───────┘ (drawn on a face of the extrusion)

The hole relies on a face created by the extrusion. The chamfer relies on an edge created by the hole. You can't drill a face that doesn't exist yet, and you can't chamfer an edge that hasn't been computed yet. Having 24 cores changes nothing: each step waits for the result of the previous one.

In our kernel, replaying the tree follows the order of this dependency graph, one feature after another. After each feature, we also have to find the edges and faces that the following features refer to: the face sketch 2 was drawn on may have been split in two by the previous operation. That tracking uses the history of the operation that just ran, so it can't start before that operation finishes.

What we can do, however, is avoid replaying everything: when you edit a feature, the unchanged features before it are reused as they are. On this kind of chain, that's a much safer saving than parallelism.

Another sequential operation, this time by design: publishing a change. When you change a parameter, the new model is computed in the background without freezing the window. But it is only published once fully computed, in a single step: you see either the old model or the new one, never a mix of both. Only one change at a time becomes the current version. That's what makes clean undo possible, and what prevents manufacturing a part from an outdated result.

2. Parallelizing isn't that simple

Where operations are independent, the work can be spread over several cores. Meshing the faces of a part is one example: to display it, each face is cut into triangles, and a face can be meshed without waiting for its neighbors. That's what we did when opening STEP files.

Here's what it brought, measured on 32 STEP files, three runs each, on a machine with 24 logical processors:

• meshing alone became 19.3% faster with four workers;
• the total opening time gained only 8.5% from parallelism;
• on some parts, the gain is zero, or even slightly negative.

Four cores for a 19% gain on the step concerned: very far from "four times faster". Why?

Not every step can be parallelized. Reading the file, resolving references between entities, building and validating the model: all of this still comes before meshing. The gain on one step gets diluted in the total time.

Faces aren't that independent. Two neighboring faces share an edge, and their meshes must match exactly along that edge, with no gap. So we sample the edges once, before the faces. Each face reads those shared points and writes only to its own results: no lock during the computation, but a sequential step beforehand.

The order of results matters. If triangles are assembled in the order the workers finish, two openings of the same file produce two different meshes. To keep the result identical from one run to the next, we wait for all workers to finish, then merge in the order of the part's faces. That rendezvous costs time. We checked that the meshes stayed identical, down to the triangle, to those of the sequential code.

The rest of the program has to follow. Diagnostic messages, measurements, user cancellation: everything that was naturally ordered in sequential code has to be rethought. Diagnostics are replayed in face order, and a cancellation waits until every worker has actually stopped before returning.

Parallelizing isn't always the best first idea. Just before this work, we had measured opening step by step. The profile mostly showed avoidable work in model validation and in the evaluation of NURBS surfaces. By fixing those two points, without a single extra thread, total opening time dropped by 30%. More than parallelism brought afterwards.

3. Decades of history

Our kernel is young, and we wrote it knowing that some parts would be parallelized. Even so, parallelizing the meshing required changing how results are stored, writing the deterministic merge, bounding memory, handling cancellation and measuring everything again.

The major CAD applications were born when a workstation had a single processor, and their code has since been extended by generations of developers. Code written for a single thread silently assumes that nobody else touches its data while it works: shared caches, structures modified in place, side effects whose full extent nobody knows anymore. Introducing parallelism into such a codebase means exposing yourself to bugs that show up once in a thousand runs, on a user's machine, and that can't be reproduced. Against a gain of a few percent, the risk of breaking files that have opened correctly for years weighs heavily.

So parallelism is more likely to arrive piece by piece, where the work lends itself to it — meshing, display, independent computations — than in the rebuild of the feature tree, which stays sequential for the reasons above.

In short

One core at 100% during a rebuild doesn't prove the vendor is incompetent. It often reveals a chain of dependencies that nobody can break. Where work is truly independent, parallelism helps, but modestly, and at the cost of real design work. And sometimes the best gain comes from simply profiling the sequential code.

If you're developing an add-in for CAD software and its performance is a problem, start by measuring. That's what we do, and it's one of the services we offer.