Mail Archives: djgpp/1997/05/15/18:17:40
In <33793055 DOT 19327180 AT news DOT cis DOT yale DOT edu> quacci AT vera DOT com (jon) writes:
>
>I program on a 486 at home, and test all of it on a pentium at work.
>
>If you mean straight multiplication and division, yes, the gap has
>been closed, more or less. But a trick like bit-shifting is still
>faster than regular division, integer or FP. And unfortunately, you
>can only do such tricks with integers.
Good point. One thing, though, I wouldn't worry about actually writing
the code using shifts; unless it's something complex, the compiler's
optimizer will probably convert it to shifts (or something even faster)
for you.
>[...]
>Oh, I've measured and measured. This is why I posted this, and I'll
>ask again- has somebody else done all the measuring already? Is there
>someplace I can know that using a case is faster than an if, or are
>static ints a plus in functions that are called a lot- stuff like
>that.
re: Case vs. if
If your compiler's optimizer is worth anything, it will probably turn a
switch...case construct into if...else if's or a table lookup depending
on which seems best to it. On the other hand, if your tests are such
that they lend themselves to a binary tree structure, you will probably
see a gain if you design your tests to minimize the maximum path. (An
optimizer might do this with a switch...case, but I wouldn't count on
it until I saw it happen.) (I once optimized a routine that performed
at least 8 tests using this method; producing a routine that contained
three times as many ifs, but had a maximum path of 3.5 tests and an
average of about 2.5.)
Another argument for ifs over switch...case is when you can reduce your
tests to ranges of values or a predefined boolean array indexed by your
test case.
re: Global/static ints:
I've found them to be slower in some cases. One thing to watch out for
is the "reluctance" of many compilers to optimize these things - you
often have to tell it it's OK by way of a command line switch or
#pragma. (The reason is that the safe assumption for the compiler is
that these values may not be stable - that is, they might be changed by
something outside of the function while the function is processing
them.) BTW, try putting commonly used constants into stack variables
rather than putting them into inner loops; sometimes helps a lot.
Finally, since "for" loops were mentioned earlier in the thread, avoid
'em. Use do...while where ever possible, and count down to zero when
feasible. You can get the "pre-test" benefit of a while by wrapping an
if around your do...while if you need to. For loops just do not seem to
optimize well compared to the do...while.-Wm
- Raw text -