Freesteel Blog » What’s this nonsense about parallel processing?

What’s this nonsense about parallel processing?

Sunday, October 8th, 2006 at 10:34 am Written by:

The article which everyone should have read is The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software.

Summary: Due to heat and speed of light limits, micro-processors are no longer going to double in speed every 18 months. However, they will continue to double in density for a while, so you will start to see 2, 4, 8 or 100 processors (or cores) running on a chip in the future. If you expect the code you are writing today to remain relevent, you need to take account of this in the code you write today.

For many CAM algorithms, there’s no excuse for not using multi-cores, since users can do it for themselves already.

Take raster passes algorithm (note to readers: do something about that page!), for example. If the software cripple (I beg your pardon, “license agreement”) permits you to, you can run two copies of your CAM system, and set the first generating raster passes on the left half, and the second doing raster passes on the right half of the model. Use the time saved to load both tape files into the same text editor and merge them.

I wonder why no one did this with two computers in the old days when calculations used to take hours.

The parallelism in the raster passes algorithm is obvious, and should be automatic, although it might take a bit of reprogramming if the code was written with no consideration for such developments. For those who are interested in taxonomies, this is MIMD type parallelism, the most general kind.

Almost all machining algorithms could be subject to a sort of MISD style, or a pipeline. We see this already in systems with visualization where the first processor is generating the passes, and a second (sometimes the “graphics” processor) is plotting them up on the screen as they get finished. Instead of this, the second processor could use its time doing the linking and post-processing, so that the front part of the tape file gets saved onto the disk before the computation is complete.

Even better, the machine tool could be set running as this tape file comes out. That way it wouldn’t be necessary for the CAM system to generate toolpaths faster than they could be cut. Unfortunately these days users want instant performance; they want to see the toolpaths that will take 1 hour to actually cut, complete and on their screens within 10 seconds of selecting the tool size. It’s a bit ridiculous. Maybe longer computation times will give better results, like finite element analysis. There ought to be a quick and easy way of checking the quality of the result, but there isn’t yet. I should write and ask if Machineworks could make something that users could download for free that would enable them to benchmark their CAM systems.

Unfortunately, that’s not where we are now. For want of a better metric, users judge the software on the speed of calculation. This makes a bit of sense, if you accept that there are good programming teams and bad (or at least under-resourced) programming teams, and that if you can’t write software that runs as fast as anyone else’s, then you’re probably a bad programming team whose toolpaths aren’t going to do too well either.

This is not what I hear, but it could be true because if there was a counter-example (bad software that ran really fast), they would make exceptions.

Anyway, the important fact is that everyone is going to have to start making their algorithms parallelizable, especially as it’s something that users are going to be able to see for themselves once they learn how to use the Windows Task Manager — the little green graph of CPU usage locked at 50%, or even 25% on a four core machine: not good.

The problem is it’s going to be expensive to convert some CAM systems to run like this. I only know the code inside Depocam/Machining Strategist, and the two basic algorithms that the problem is going to be with are Scallop (which includes the much dreaded rest area detection) and Pencil milling. I certainly wasn’t interested in multithreading at the time wrote those, and I may have made a couple of arbitrary choices early that will take months of expensive developer’s time to unpick. It’s like packing a bag and putting the toothbrush at the bottom. Very inconvenient and unnecessary to have put it there, but it’s too late now. Maybe they have already made the substantial investment; I don’t know. No one’s asked for advice.

Anyway, the news is we think we’ve worked out how to parallelize all our new versions of these algorithms, except the Adaptive Clearing one. Until we get access to some multi-core machines, we won’t know if it is sound or makes a substantial difference in performance. It’s possible to fail by having the multiple calculations clashing with one another such that they’re busy all the time exchanging partial results between themselves, rather than getting any work done. In the meantime, we’re going to buy a copy of VTune which Martin is at present teaching himself how to use.

News from a week ago: Quad-core processor forecast.

1 Comment

  • 1. CAM – A great inven&hellip replies at 9th August 2011, 3:00 am :

    […] parallel processing technology is so complex and hard to be mastered that often CAM developers struggle to adopt it entirely. But it has proved to be the key element to deliver the demanded […]

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>