Re: Run-time checking and speed

[dodger@gcr.com (Roger Labbe)]

Tony posts 3 variants on a nested loop and asks what differences
there are in run time efficiency.

Tony, it depends on the efficiency of your compiler. All the 
three examples you gave can be type checked at compile time and
so a good compiler would not generate type checking code. If any
example would confuse the comiler it would be the first one, which
doesn't define subtypes for the range 1..100. Still, the compiler I
regularly use figures out that no type checking is needed.

In general, it is difficult to predict what code a compiler will
generate unless you look at a lot of assembly code generated by
the compiler. For example, we would all expect that copying
arrays by slices would be faster than by a for loop since the
compiler can optimize the former with a move block instructions.
However, the compiler I use often generates MUCH faster code
for the for loop. Why? Unless copying a simple type such a 
integer or float it calls a routine that copies the data
bit by bit (yes, you read that right!). 

That's an egregious example; my point is if unless you plan to
never reuse your software or use a different compiler (or version
of the same compiler) you can't really optimimize at the source code
level. Most of the preferred coding practices, such as strong
type checking, copying by slices (despite my contrary example),
record assignment using aggregrates, etc., usually lead to the
best assembly because they give the most information to the compiler.

I can't speak for other real time developers, but I code for 
maintainability first and speed about last. Speed becomes a factor
only in small pieces of code, and this code is usually isolated
to i/o or heavy duty computation. These pieces of code are most
likely already isolated (encapsulated) if you have a good design,
so optimizing the small piece of code is fairly straightforward.
A standard piece of advice re optimizing is "make it right, then make
it fast." Use all the features of Ada you deem suitable to make
it right; you can always recode slow parts later, and you will have
the original code to both document your new (probably obscure) code
and to test its correctness.

I have a feeling I might have strayed from the intent of your question.
There is obviously a lot more to say about real time design, and
things aren't as simple as the last paragraph suggests. An excellent
strategy is to combine rapid prototyping with an evolutionary approach
to quickly find the significant limitations of your machine/compiler/tool/
programmer mix. You can then focus on those problems early in the
design cycle, and use the ideas in the previous paragraph for less
than critical problems. I promise that which of three types of for
loops are the most efficient will be in the noise level in most aspects
of your work. In the few cases where it is significant you can code
all three cases and see which is best. Recognize when you get a new
version of your compiler that work may be invalidated, so don't chase
unattainable goals.

If I missed your point or you have further questions, just ask.
Obviously this is a subject that interests me.

Roger Labbe