Knowing .NET

Archive for the ‘Published’ Category.

Writing A Technical Article, Pt. 3: Research Begins…

September 11, 2007, 12:00 am

I’m not one of those people for whom the task of composition is a somewhat mechanical extension of increasingly detailed outlines. Nonetheless, research consumes between 80-90% of the time I spend on a technical article (note I said time and not effort — subjectively, writing text is two or three times harder than writing C++. You can satisfy a compiler.)

In this case, research will consist of:

Integrating CodeAnalyst and Eclipse
Profiling a simple application
Implementing an image-processing application
Profiling it to discover a performance problem
Investigating that problem with CodeAnalyst
Ameliorating it
Evaluating the performance “win”
If not “big enough” go to 3

In this case, my target sample application has two algorithms that I think will be difficult:

Seam-discovery (CPU intensive)
Seam-removal (Memory-manipulation intensive)

With seam-discovery, I know that even if I implement a known-good algorithm (such as graph-cuts), I am guaranteed to peg the CPUs. My big gamble professionally is that I’m a good enough programmer to find a Step 6 “win” that I can pull off in a reasonable amount of time. A safer bet would be to choose an algorithm that would have performance problems if intentionally implemented in a naive manner (for instance, a filter that just iterated across rows and columns and, at each pixel, retrieved the neighboring pixels and averaged them. Pretty easy to tune that up!)

Now, a confession. By the time you read this, I’ve been somewhere not-Hawai’i for a week or so. I’ll carry print outs of this paper on content-aware image resizing and this paper on graph-cuts and study them on the plane tomorrow. I’ll have my laptop with me and may noodle around with source code, but it’s far more likely that I’ll be working with pen and paper to see if I can “get” the algorithm intuitively. Other than that, I’m going to do my darnedest not to spend too much time thinking about computers.

Coming September 19th or thereabouts: Part 4, Research Gets Underway…

Category: Concurrency, Languages/C++, Published | Comments Off

Writing A Technical Article, Part 2: Gathering Tools

September 6, 2007, 12:00 am

Probably the biggest difference between academic and commercial writing is this: academic writing is almost always concerned with algorithms and process, commercial writing is almost always driven by a specific set of technologies. In this case, I’m being paid by AMD to explain integration of CodeAnalyst and Eclipse CDT. So that dictates that I’ll be using C++, which leads to a couple questions:

Linux or Windows?
What C++?

The Linux or Windows question is fairly easy for me to answer: I boot into Windows and run Linux in Virtual Machines. For an article on a profiler, the VM is a complication — CodeAnalyst works within a VM, of course, but since I expect this article to get down to the hardware, I don’t want any confusion about how toasty-warm my code is making my Opterons. So I’ll be experiencing the code in Windows.

But when writing about Eclipse, surely I should imagine that my target audience is not strictly Windows-based. So it seems logical to set up a compiler-chain based on GNU C++: I know that will be portable. (Note: I’ll probably cross-compile with at least Microsoft C++ and compare the experience. That might give me enough information for, if not an article, at least a column.)

Since the article is supposed to emphasize multicore/multichip development and in C++, it’s a no-brainer that I’ll be using OpenMP.

My next thought is unit-testing. For one thing, I just don’t develop anything without unit-testing anymore. For another, repeatability is critical to the article. For a third, I expect to hit some hard problems along the way and unit-testing is the best way to maintain momentum in the face of brain-twisters. I have not compared C++ unit-testing frameworks, but Boost has a test component, and while there may well be better, I know that Boost won’t be poor.

Version control is not the same issue in an article that it is in professional development, but you can never over-estimate the benefit of a backup: I’ll be using Subversion against a local server.

Since I know that I’ll be doing image-processing, I’d just as well use a library or two to handle file-loading and basic pixel manipulation. If I were building an application, I’d definitely tend towards GTK+. However, I want to keep things as simple as possible around the algorithm(s) that I’ll be developing, so I’m going to see how far I can get with this project, CImg, which seems nice and minimal.

So my initial tool list is:

CodeAnalyst : Profiler
Eclipse CDT : IDE
GCC : Compiler-chain
OpenMP : Shared-memory parallel programming
Boost.Test : Unit-testing
Subversion : VCS
CImg : Image-processing library

If I need or change libraries, I’ll make mention of it in forthcoming posts.

Next: Part 3, Research Begins…

Category: Concurrency, Languages/C++, Published | Comments Off

Writing A Technical Article, Pt. 1: Background

September 3, 2007, 9:01 am

I thought I’d try blogging the development of a technical article; it might prove interesting to, I dunno’, 3 people in the world.

I’ve been contracted to write a 2,500-words-plus-listings article on using AMD’s CodeAnalyst profiler with Eclipse, especially relating to multithreaded / multicore development. So that’s a pretty beefy article, about twice the length of a typical technical article in a print magazine. CodeAnalyst works with native code, so my sample program(s) pretty much have to be written in C++ — anything else would limit the audience.

AMD targets an experienced audience, so the educational goals for the article are “The reader will be able to…”

… enable and gather data using CodeAnalyst from within Eclipse CDT
… navigate within the main profiles provided
… recognize the profile most clearly associated with their performance limits
… determine the source-code lines associated with a performance issue
… after making code changes, compare the performance of subsequent runs”

Which is a heck of a lot of ground to cover. So the end result will be something like an advanced tutorial that you might get towards the end of a piece of documentation.

My professional goals are to deliver a technically sound article that satisfies my client’s goals within a profitable range of hours. I can control that primarily by manipulating my sample program(s); the amount of time I need to research the actual use of Eclipse or CodeAnalyst is minimal, since I know both products. The research aspect of the article — always the most time-consuming in a technical article — will be the development of sample program(s) that:

have a performance-limit that can be ameliorated,
are comprehensible, and
can be distributed (this limits my use of libraries)

My personal goals are to make sample programs that are interesting in and of themselves. This is a weakness on my part, but what can you do? In this particular case, I hope to implement some significant part of the algorithms used for content-aware image resizing. I have no intention, or interest, in recreating the GUI shown in the video. I have neither the time nor, quite honestly, the mindset — once I see the algorithm work, I can guarantee you that my interest in this will virtually disappear. That’s one reason why I’m not rich.

Next up: Part 2, Gathering Tools