In C/C++, it is common to compile some sections of code conditionally, e.g. debugging code, new untested features, cross-platform support, etc. The most common way to conditionally compile code is to use the #define preprocessor directive, then bracket conditionally compiled code with either #ifdef or #if.

Here is a simple #ifdef example:

#define DEBUG_SYSTEMX  //remove this #define to disable (e.g. comment-out this line).
//...
#ifdef DEBUG_SYSTEMX
    //... system x debugging code ...
#endif

And, here is a simple #if example:

#define NEW_FEATURE  1  //change 1 to 0 to disable
//...
#if NEW_FEATURE
    //... new feature code ...
#endif

Both of the above accomplish the same thing (conditional compilation), but they have different implications, e.g. the following will cause a compiler error when DEBUG_SYSTEMX is defined:

#if DEBUG_SYSTEMX  //BAD! #if WHEN IT SHOULD BE #ifdef
    // ... system x debugging code ...
#endif

However, when DEBUG_SYSTEMX is not defined, the code will be compiled out because the preprocessor treats undefined macros as 0 in conditional tests (which just so happens to match expectation).

The following would not work as intended, either:

#ifdef NEW_FEATURE  //BAD! #ifdef WHEN IT SHOULD BE #if
    // ... new feature code ...
#endif

Because NEW_FEATURE is always defined (to either 1 or 0), #ifdef NEW_FEATURE is always true, and the supposedly “conditional” code is always compiled.

So, both cases (#ifdef and #if) have problems if you accidentally use the incorrect test.

Of the two problems, using #ifdef when it should be #if appears to be the more serious error, since it can result in unintended code being included in a build, and no compiler errors or warnings will be generated (unless the conditional code happens to depend on other code which gets compiled out).

However, using #if when it should be #ifdef does the correct thing when the macro is undefined, and it generates a compiler error when the macro is defined (making it simpler to track down).

In this regard, #ifdef appears superior, but there are other considerations which should be taken into account. I’ll delve into some of those considerations (and cases you can’t do much about) in following posts.

I used to pronounce “Linux” with a hard “i” [as in "Aye, aye, captain!"], since it rhymes with the way we pronounce “Linus” in English.

Seems natural, doesn’t it?  I mean, considering that the creator’s name is “Linus”, right?

However, Linus Torvalds is Finnish, and in Finnish, the pronunciation of the “i” in his name is closer to a hard “e” (not a hard “i” as in English — his name is more like “Lee-noose” than the English “Lie-nuhs”), so he says that Linux is pronounced with a soft “i”. I assume that he feels a soft “i” is closer to a hard “e”, and I would agree — not that it matters at all what I think — he’s the creator of “Linux” and can pronounce it any way he wants — even if he decides the correct pronunciation is “Eunuchs”.

Did I go there?  Yes, I did.  Sorry, but look up more info on “Unix”, and you might be surprised…

On that note, Linus tells us how to pronounce Linux with a soft “i” in this YouTobe (and also his name — in 3 languages, no less — show off! j/k).  Not that this is anything new, but at least I’m glad I finally understand it.

Intro

This is the first in a series of “thought pieces” about concurrent programming, especially as it relates to realtime applications. The motivation is for use in games, but this series is not game-specific.

The concurrent programming debate

There is a lot of interest (and griping) these days about the problems of writing efficient bug-free concurrent code (especially in the context of multicore systems). If you’re reading this, you probably already know why it has become a hot topic, so I’ll skip the explanation.

In any case, many people seem to feel the same way as guru Donald Knuth, author of the highly regarded The Art of Computer Programming series. This is what he said in a recent interview.

…I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks!

However, some people feel differently. Contrast Knuth’s statement with the following quote [from a lecture given in 1977] of another guru, John Backus, famous for being the “Backus” in BNF (Backus Normal Form, aka Backus Naur Form) formal language specification:

Surely there must be a less primitive way of making big changes in the [data] store than by pushing vast numbers of words back and forth through the von Neumann bottleneck. Not only is this tube a literal bottleneck for the data traffic of a problem, but, more importantly, it is an intellectual bottleneck that has kept us tied to word-at-a-time thinking instead of encouraging us to think in terms of the larger conceptual units of the task at hand. Thus programming is basically planning and detailing the enormous traffic of words through the von Neumann bottleneck, and much of that traffic concerns not significant data itself but where to find it.

To be fair, Backus was talking about changes in programming paradigms (specifically, proposing the use of functional programming), not parallel processing, but his point that there must be better methods of programming that transcend “word-at-a-time thinking” still seems relevant today.

Is the debate moot?

It may seem that debating concurrency is pointless. After all, we’ve started down the multicore path, and it seems like there is no turning back. That is probably true. For the foreseeable future, hardware will continue to increase in concurrency.

However, it is conceivable that software might remain procedural/imperative (e.g. if someone solves the long-standing problem of automating parallelization of sequential code). In addition, deciding how to approach the problem of concurrency depends on how we perceive the advantages and disadvantages of mimicking sequential code.

So, I do not think the debate is entirely moot. It is largely moot for hardware, but not for software, especially insofar as it affects our perception.

What’s my take on concurrency?

I agree with John Backus’s sentiment about the state of programming. A lot has changed in the 30+ years since his lecture, but even now, the status-quo of programming languages and methodologies feels limited by the intellectual “von Neumann bottleneck”.

In fact, I believe concurrent hardware will lead us to languages and methodologies which more naturally express solutions to realtime application problems. After all, realtime applications are about simulating large numbers of simultaneous activities. Simulation is naturally concurrent. All this time, we’ve been trying to simulate concurrency with sequential programs.

But, if simulation is naturally concurrent, why is concurrent programming so difficult?

The problem is that we don’t yet have adequate languages, tools, and methodologies for dealing with processor concurrency. Once those are developed, concurrency will be liberating. We will finally be able to write realtime applications the way we always wanted to (but didn’t know how).

Fortunately, the development of those languages, tools, and methodologies will be expedited by the fact that no one can ignore concurrency any longer.

[to be continued....]

About 5 years ago, I worked at a division of Brooks Automation which built semiconductor wafer-sorting robots. My most interesting project was creating an experimental image-processing algorithm to detect a reference notch on a silicon wafer (which is used as a reference position for etching — we used it to locate ID numbers and barcodes). It was a challenging project — the reference notch is a rather small feature that only occupies a few pixels in a wafer image.

I was excited to demonstrate that the project should work in principle, so I threw together a prototype as quickly as I could. I made it very clear to everyone (including management) that this would be a prototype only, that it was unsuitable for mass-distribution, and that I would need some time after the demonstration to rewrite the code.

So, after about 3 weeks and with the help of some hardware tweaks (to provide a high-contrast image) I got it to detect the notch location about 90% of the time. Not bad for a first pass, but clearly it would need a lot of work to get that up to production quality (somewhere above 99%).

But, there was a problem…I had used a lot of “rapid prototyping” techniques (and hacking) to get things done as quickly as possible. I had used smart pointers instead of proper memory management, and as a consequence, there was a lot of memory waste (holding on to unnecessary images in the image processing chain) and thrashing/fragmentation (caused by allocation/deallocation of image buffers which could have been reused). The algorithm worked, but it was slow. I don’t recall exactly, but I think it took about 3 seconds to process an image.

But I thought “Not to worry, with some additional time to rewrite proper memory management routines, plus optimizations, that will easily reduce to half a second or less.”

The next day, my boss told me that we would use the code as-is.

I explained that the code was not ready for production, that I needed time to rewrite. I explained about the memory management problems and how optimization would require a different code structure. I also reminded him again that I had been upfront about the need to spend extra time for a rewrite (I had reminded him almost daily because I anticipated such a problem). He still wouldn’t budge and insisted that I continue with the current code base.

That’s when I learned the lesson which became the title of this post: Your prototype is your final product.

It’s a good thing to remember. Whenever you work on code (or engineer any product), what you think of as a prototype is likely to be seen as a final product by management. Once management sees visible results, they want it right away. And, in many cases, they just don’t understand the value of improving things that are “under the hood”. After all, what they see seems just fine to them, so what value could there possibly be in improvements?

[to be continued...]

As you can tell, there was a really long gap in my posting. During that interim, I had worked on several posts, but none of them were completed. There are a few reasons for that:

1. I like to make my posts as clean and clear as possible, so I tend to spend a lot of time writing them.
2. The posts I had been working on are quite long, so there is a lot that needs to be edited.
3. I’ve been trying to delve into topics that are not yet “solved” (e.g. parallel programming). I’m still trying to formulate my own thoughts on those topics, so I’m never sure how to present them.
4. I also write on topics that go against the grain of “accepted practice”. That requires compelling arguments to keep people from thinking I’ve gone bananas, e.g. a post about why innovation isn’t always a good thing… See, bet you’re thinking “bananas” already [you'll understand when I get to it].

Anyway, the end result is that I haven’t posted anything.

So, I’m going to get back to it by breaking up long articles into series of posts. That will probably be better, anyway. Who really wants to read a gigantic article all at once?

Now I just have to figure out a good way to link series together so they can be found as a unit (on the off chance you do like reading gigantic articles after all).

One of my co-workers has been finding (and sometimes correcting) typos in our code. One of the typos (which is in almost every game engine at one time or another) is “frustrum” instead of “frustum”. I suggested that we compile a list of common typos and title it “There is no rum in frustum”.

Coworker: Hey, John. How’s that code going?

Me: Well, it’s looking pretty good. I just fixed the last bug we know about … And you know what that means, right?

Coworker: It’s done?

Me: Well, no … Not quite.

Coworker: What’s it mean, then?

Me: It means there’s a lot we don’t know.

Today, I found this quote by Charles Babbage on Wikipedia:

On two occasions I have been asked … “Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

Now, there’s something any programmer can sympathize with!

I finally picked up a 1 GB USB flash drive [actually, it was a few months ago, but I digress].

Maybe it’s because I’m an “old timer”, but 1GB in a tiny package at an “impulse buy” price point is just incredible. No wonder the 1.44 MB floppy disk is dead. This little flash drive holds almost as much data as 700 of those floppies, it’s small enough to leave on your keychain, and it’s far more durable.

Thinking even farther back, I remember when I loaded programs for my Atari 800 from a cassette tape! It took several minutes just to load a few dozen K of data. It was a big deal when I finally got a 5-1/4″ floppy drive. I got a special “double-density” drive which held about 180KB (you could flip the disk over to get another 180KB, for a total of 360KB)…So my flash drive holds almost as much as 3000 of those old floppies! Wow.

My “production diary” entry was posted on the Mercs 2 website about an hour ago. I tried to have a little fun with it, so we’ll see what people think…