Irritating code found in the middle

Thursday, September 28th, 2006 at 11:10 pm

We’ve been developing a way to make most of the machining algorithms work in parallel to take advantage of these multicore processors that are beginning to have around here. Unfortunately, the Danes beat us to it, and have put in their own versions of some of the necessary modules. There’s one which is concerned with avoiding testing the cutter against the same edge multiple times, and you do it by marking that edge with an integer.

It’s a common trick. The naive version is to put a bool into every edge, set all values to false at the beginning of a run and then set the value to true as you encounter each edge. This way you can tell whether you’ve seen the edge before. Unfortunately the loop where you reset all the values to false at the beginning of the next run takes time.

The better version is to use an integer which is set to zero originally. You then increment a register at the beginning of every run starting with one. This number is not the same as any of the zeros associated to any edge, so if you set it to one every time you visit an edge, you can tell that you have seen it before. For the next run you start with two, which is a number not shared by any of the values already there.

It’s simple and effective, and easy to understand because everyone knows what an int is. Unfortunately, for some programmers that’s too straight-forward, and they prefer ruin it by randomly wrapping the integer into a pointless class with a stupidly generic name that enables the gratuitous reuse of a variable name, and we get something like this:

```class SurfaceHitRegistry {
private:
struct Record {
int hitId;
};

vector<Record> edgeRecords;
unsigned int hitId;

SurfaceHitRegistry() {
hitId = 0;
}

inline bool HitEdge(unsigned int edgeId) throw() {
Record& record = edgeRecords[edgeId];
bool result = record.hitId == hitId;
record.hitId = hitId;
return result;
}
}
```

Oh well. I’ll put up with it for now.

• 1. Neel replies at 29th September 2006, 9:55 am :

Are you implementing mulithreading ? what are your initial test results , how much toolpath processing time did you save using multithreading on dual core processors?

• 2. Julian replies at 1st October 2006, 2:35 pm :

It’s all multithreading already. What this is about is parallel processing within the algorithms. The algorithm for scallop, pencil, rest area, and zcontours are all fundamentally the same (the way I’ve written it), and they are such that they can calculate to an arbitrary degree of parallelism. For example, each processor can calculate one quarter of the rest area region, and then the areas can be merged into the result.

We have no idea how much time this will save. There is a big deal about processor caching which we know little about.

Do you have a 4 or 8 core machine and would be able to try out our initial attempts, just to see if it makes a difference at that scale?

• 3. Neel replies at 4th October 2006, 6:06 am :

I have a AMD athlon 64 X2 Dual core processor 4400. Do you think that the processing time will be half on dual processor or a reduction of 30% in processing time over single processor PC. I have read that multiprocessor can drop in the performance because they gain non-linearly on the power consumption and heat generation.

• 4. Neel replies at 6th November 2006, 7:42 am :

>>We were just putting together an install exe file of it to try. Comes
to about 9Mb. Can you take that by email, or do you prefer a http link