void main(void)

Calls, Returns and In-Between.

November 2006

It always pays to look at things from different angles, and data-intensive applications are a good place to apply this principle. But arranging all that data in lots of custom ways can get pretty inefficient pretty fast. The answer is a View object: an extensible and scalable approach that allows multiple views of your data without multiple copies of that data. Gabhan Berry demonstrates the principle in his article "C++ View Objects."

And speaking of looking at things from different angles, it seems I should have looked at the subject of my last blog post from a few more angles before opening my mouth. My statement that:

"Certainly the idea of running code on multiple pieces of hardware, (whether in separate rooms, on separate chips, or on the same sliver of silicon) was science fiction for the average user just a few short years ago."

drew this response from astute reader Ed Weir:

"Unless, of course, you had a Commodore-Amiga box with an Intel bridgeboard. Specialized chips running specific processes under control of the CPU started a bit further back with the Commodore 64. Interprocess communication was fairly easily accomplished via AREXX and the AREXX ports that many commercial tools had implemented."

So unless you'll accept the implausible excuse that by "a few short years ago" I really meant "1986," I suppose I have a little crow to eat. Truth is, multiprocessor machines really can't be called "new." Ed was also kind enough to rustle up the following links for more information, which I relay here:

• The Amiga 1000 came out in 1985
• The "Sidecar" came out in 1986
• The Amiga 2000 came out in 1987, with the Bridgeboard (updated Sidecar) available.
• AREXX is a "glue" language, based on the multiplatform REXX. What the article neglects to tell you is that the glued applications were running simultaneously on the machine (multitasking).

One last fascinating Amiga note from Ed:

"Until recently my cable company (Comcast) was running at least some of its' channels on Amigas. How do I know? When a station went down, the Amiga error message displayed."

Posted by Kevin Carlson at 01:58 PM  Permalink |

One of the great truths of application development is that the exotic eventually becomes commonplace. Time was that multiprocessor machines were almost exclusively made by a company called Cray, and most mere mortals never laid eyes on one. Certainly the idea of running code on multiple pieces of hardware, (whether in separate rooms, on separate chips, or on the same sliver of silicon) was science fiction for the average user just a few short years ago. Today it's becoming the norm. And developers must keep pace.

Challenges arise from the growing prevalence of cluster environments (see Cluster Computing: Leaps, Bounds, and Bottlenecks), as well as the multicore revolution (see Multicore Meets Virtualization). C++ is changing to meet those challenges, but change comes slowly, and only after much deliberation. Which is good—no one wants hasty, ill-considered changes to the standard library, or (worse still) to the language itself.

Sure, C++ programmers already have workable solutions for multithreading. But they haven't been part of a standard, and have left developers with a jumble of platform incompatibilities, and no guarantees from their compilers that anything will work reliably everywhere. That is changing, however. Threading is directly in the crosshairs of the C++ standards committee, and threading-friendly changes to the language are expressly intended to be a part of C++0X. There are some great ideas on the table. For an overview of what's been said so far, check out the dirt from the latest ad-hoc meeting.

Posted by Kevin Carlson at 05:01 PM  Permalink |

Successful compiler optimization requires a plan. First, characterize your application so you know where to look for performance increases. Second, prioritize your optimizations. Third, select a benchmark. Only then are you ready to evaluate the app's performance. Max Domeika and Harry Singh from Intel use MySQL as an example app as they discuss optimizing compiler settings for Intel processors.

Posted by Kevin Carlson at 04:38 PM  Permalink |

A few weeks ago, Pete Becker showed us some ways to avoid buffer-overflow vulnerabilites when using string-manipulation functions. Robert Seacord warns us that integers are an underestimated vulnerability, partly for the same buffer-overflow reasons, but partly for much more unexpected reasons.

Posted by Kevin Carlson at 12:33 PM  Permalink |