MBALOVER said:
My objective is to make my program written in C as fast as I can.
I read somewhere that I should avoid accessing an array too much
because it takes processor's time. Is that true?
For example, is Version 2 faster than Version 1?
for (i=0;i<1000;++i)
{
if (A[5]>8)
printf("helllo");
}
int A[10];
A[5]=10;
B=A[5]; //<== Now I use variable B instead of the A[5]
for (i=0;i<1000;++i)
{
if B>8
printf("hello");
}
There's no way to say for sure. You have two things: there's the
C language and then you have a compiler that converts a program
written in C into machine code (not to go into too much detail).
The C language doesn't state "doing something this way will be
faster than doing it some other way." How fast things are going
to be depends on how the the compiler converts the C program into
machine code.
There's a good chance that the compiler will notice that you
use A[5] over and over again in a tight loop in version 1, so
it may just emit code for you version 1 that is roughly equiva-
lent to that for your version 2 (with the value of A[5] stored
in a CPU register).
But if you look at the two versions of the program (disregarding
syntax errors;-) you immediately will see that there's an even
"faster" version
int A[ 10 ];
A[ 5 ] = 10;
if ( A[ 5 ] > 8 )
{
for ( i = 0; i < 1000; ++i )
printf( "hello" );
}
since with this version you don't do all the (redundant) checks
within the loop over and over again. The compiler may be able
to notice this and output machine code that is equivlent to code
generated from version 3, even for version 1 and 2 of your pro-
gram.
But the compiler may even notice that A[5] is always larger than
8, so the machine code you may end up with could very well be
just the equivaled of
int A[ 10 ];
A[ 5 ] = 10;
for ( i = 0; i < 1000; ++i )
printf( "hello" );
or even
int A[ 10 ];
A[ 5 ] = 10;
print( "hellohellohellohello/ repeat 995 times /hello");
So, you can't say "If I write something this way it will be
faster." The C language hasn't any built-in guarantees for
any of this. If something is faster or slower depends on how
good the compiler you use is at optimizing the C code you
pass to it for the machine it's going to be run on.
Getting compilers to create faster machine code is an on-going
effort. Compilers have gotten quite good at that and the usual
recommendation nowadays thus seems to be to write code that's
easy to understand and let the compiler take care of optimiza-
tions (writing too convoluted code may even throw off the com-
piler and result in slower execution). Only if there's a bottle-
neck you found by actually measuring how much time is spend at
certain parts of your program it makes sense to worry about re-
arranging the C code in order to help the compiler to emit
faster machine code (and then this will probably only work
with the compiler you did the measurements with and on that
architecture, using a different compiler or architecture the
same "improvements" may end up being contraproductive).
There's a lot of folklore to be found about "this will result
in faster code" but be wary of such claims - they may have been
correct 20 years ago when compilers weren't as good as they are
today. If you really need utmost speed (with a certain compiler
on a certain architecture) the only thing you should trust is
careful measurements and not believe in some "I read somewhere
that this is faster than that." statements.
If you are interested what happens mainly out of curiosity then
having a look at the assembler code generated by the compiler
might be enlightening. But just don't assume that the results
you get from one compiler will be the same as that fron another
one.
Regards, Jens