Some [More] Notes on the Abstraction Penalty for IA86 C++ Compilers

I just happened to run across Dan Piponi's Some Notes on the Abstraction Penalty for IA86 C++ Compilers, which looks at the code generated for the function:

int test1(int z) {
    Matrix<static<int,3,3> > m;
    Vector<static<int,3> > x;
    m[0][0] = 1;
    m[0][1] = 0;
    m[0][2] = 0;
    m[1][0] = 0;
    m[1][1] = z;
    m[1][2] = 0;
    m[2][0] = 0;
    m[2][1] = z;
    m[2][2] = z;
    x[0] = 1;
    x[1] = 2;
    x[2] = 3;
    return (m*x)[2];
}

This function (with the appropriate template definitions) multiplies its argument by five.

The Microsoft compiler (version 13.10.3052) generates three instructions: a mov, a lea, and a ret; the lea instruction multiplies the argument by five. GCC (version 3.3.1) produces about 150 instructions, one of which is a call to a matrix-times-vector function. The famed Intel compiler (version 8.1) produced something like 50 instructions.

Now, on the one hand, the Microsoft and Intel compilers have a significant optimization advantage (which is irrelevant in this case) in only compiling for one architecture. GCC's optimization capabilities are excellent in the dancing elephant sense: given everything GCC does, it optimizes amazingly well. On the other hand, this example involves template expansion and inlining, neither of which really involves the architecture.

However, GCC has significantly improved its C++ support in recent versions, so I wanted to find out what a more recent version (4.1.1) would produce using -O3. Here it is, in all its glory:

_Z5test1i:
.LFB1623:
        leal    (%rdi,%rdi,4), %eax
        ret
.LFE1623:
...

nm reports that the function is 4 bytes, versus 853 unoptimized or 135 with -O2.

$ nm  -t dec --demangle -S a.out  | grep test1
0000000004197344 0000000000000012 t global constructors keyed to _Z5test1i
0000000004197376 0000000000000004 T test1(int)

Some progress has been made.

Requirements...

Shortly after I moved to the Huntsville area, I had an interview with some nice folks from Colsa at the Software Engineering Directorate on Redstone Arsenal. They were looking for someone to work on the new Systems Test and Integration Laboratory. (That STIL link is completely unrelated to the SED or Redstone, but is the best description of the project that I have found.)

During the interview, I was asked a couple of variations of the question, "What would you do if you were given a set of totally evil requirements?" I babbled a bit, thought about it a somewhat too long for them, and the best reply I could come up with involved the word "prototypes".

Thinking about the interview later, I had serious trouble trying to decide why I had such a difficult time with the question. What finally came to me was that I had never been given a set of requirements! In my entire career, since I graduated the first time, I have never been on a project that involved a set of requirements handed down from above!

Sure, I have worked on projects that had requirements documents, such as the IBM WorkplaceOS project (such as it was), but that was ages ago, and my portion of the project was to write benchmarks to exercise the system; there were no written requirements for my part of the project. (Had there been, it seems likely that the framework I was basing on would not have had some of the monumental bugs that it did. Like the parameter that was supposed to represent an error percentage with a default of 10% but actually was just used as a divisor; the default of 10 works since x/10 == 10% of x, but no other value would....)

This seems to be a significant difference between Huntsville and Austin. In almost all of my previous (and current) jobs, I was expected to figure out the requirements myself. At best, I was given an initial problem definition ("This server soaks up too much memory. Fix it.") or some other prototypical system or reference implementation. And the best (and only reliable) way I have found to weasel out requirements is to give the customer something they can play with, so that they can provide me with complaints. Just asking the customer for requirements beforehand would be like asking a bobble-head; a magic 8-ball would be an improvement.

Anyway, I did not get the job. I was very disappointed. The work they are doing in the STIL is seriously cool.