Evan on Engineering Software

In last week's upFront.eZine, Ralph Grabowski, in an article talking about UGS Solid Edge, said:

"UGS sees no advantage to multi-core CPUs (which Intel and AMD are pushing), because most software, including CAD, does not multi-thread easily. ("Multi-thread" means parts of the software can be handed off to the second CPU and executed independently.) We tend to work consecutively with CAD software, not concurrently."

This week some of his readers took exception with UGS's position (as reported by Ralph), saying:

"CAD apps should easily benefit from multi-core CPUs and multi-CPU computers: sorting, stuffing the OpenGL pipeline, lots of numerical things like FEA, even handling user interactions can easily be divvied up amongst CPUs."

and

"As far as I know, multi-threading has very little to do with the user's consecutive inputs, but with the knowledge that a lot of intense image/vector processing can be accomplished in parallel to great advantage."

Here's a situation where nuance is important.  UGS has been shipping multi-threaded software for at least 7 or 8 years, and probably longer.  Parasolid and Nastran NX are both SMP (symmetric multi-processing) capable. UGS isn't saying that they can't do it, or that they don't do it.

I suspect that what UGS was trying to convey is that, in the realm of CAD (ignoring the geometric modeling kernel), there are not that many things that really benefit from multi-threading.

Take a look at the examples given by Ralph's readers:

• It's not my experience that CAD programs actually do much sorting, but, in any event, I believe the process is memory bandwidth limited, not core limited. 
  
• "Stuffing the OpenGL pipeline" doesn't seem to offer many opportunities for multithreading, though tessellation of surfaces could certainly be parallelized (it's most commonly done by GLU -- the OpenGL Utility Library -- however, there has been some work on implementing tessellation on the GPU.)  The thing is, this is a downstream process from CAD.  It's not part of CAD itself.
• User interactions typically involving clicking on something.  The most significant user interaction, object selection, might benefit from multi-threading (with enough work) -- however, I've found a greater than 100:1 difference in selection performance when testing a number of CAD products (with the fastest being less than 1/2 second to window select 1 million objects.) It would seem to be a waste to use multi-threading to fix a problem caused by poor program design.  Other than this, user interactions typically happen so fast that they wouldn't gain any meaningful performance from multithreading.  How fast do you need dialogs to pop up?
• Image processing can benefit from multi-threading, as images can be partitioned.  Yet, in the realm of CAD,  how much image processing is there?
• Vector processing -- at least for typical CAD software -- is not a bottleneck.  Quaternions and other forms of math used for affine transformations in CAD programs are pretty fast.  Granted, if you start looking at surface and solid modeling, it can be a different beast -- but then, you're looking at the geometric modeling kernel, not at the CAD program itself.
  

Looking at mainstream MCAD programs such as UGS Solid Edge, I don't see any gross performance problems.  Yes, Solid Edge will bog down with really large models (though it bogs down less than some of its competitors.)  The cure for this may include some multithreading (such as that which is already in Parasolid), and some graphics optimization -- but the biggest benefit is likely to come from retuning the program to take advantage of the very large memory capacity available with some 64-bit computers.