| No, but to be fair you'd have to take account of the extra
costs with MACRO:
o Only runs on VAX and AXP
o Roughly twice the coding time
o Far less maintainable
I suspect:
o the performance of well-coded VAX MACRO is far better
than vanilla C (on VAX only);
o that good C coding practices can make up some of the
difference;
o that poorly-coded MACRO is no better than vanilla C
and often slower;
o and that considering commercial reality, you'd have to
be nuts to go with MACRO for new development.
-John Bishop
|
| Re: .0,.1,.2:
My favorite example to use in this case is a common code fragment in our
system which is an object-oriented runtime environment for dispatching method
invocations. The dispatch is a little more complicated than in a language
like C++ where a pointer to a function can just be de-referenced; we have to
lock access to the object [it's a multi-threaded runtime environment] and
fault the object definition and value into memory if they're not already
there, perform security access checks if the client has the rights to invoke the
object's method, and then finally call the actual method.
As you can imagine, it's something of a bottleneck, so I decided to hand-
optimize the code that VAX C generated for the routine. In every single way I
could quantitatively measure before execution, the code sequence I came up with
was better -- fewer memory references, fewer registers used (and therefore saved
in the procedure entry mask) fewer instructions.
However, it ran three times longer than the VAX C-generated code. (The C
code dispatched 40,000 messages per second, the hand generated code did a little
over 10,000 as I recall.)
That was my last foray into hand-generated MACRO code. I love knowing what's
going on at the lower levels, but on a VAX processor, alignment must be big
magic which I doubt a human can manage as well as the VAX C compiler/VCG. Not
to mention the portability and maintenance benefits of a higher level language.
-mjg
|