Arne Demmers wrote:
Please provide some context. You can't be sure that the people reading
have seen (or can remember) the article you are replying to. In this
case something as simple as:
<snip advice about optimisation>
might have been sufficient. See
http://cfaj.freeshell.org/google/ for
details on how to get Google to do the right thing and other useful advice.
So what you all suggest is trial and error.
No, most of us are suggesting in the first instance *don't* try to
optimise your C, write it to be clear.
If, and only if, you have ensured you are using the best algorithm, you
have written clear code and proved it to be correct, and you have
measured it and found you really do have a problem, do you consider what
to do about optimising the code.
Having got through the above and found your really do have to do
something. What you do is measure. Then you measure some more.
Eventually you will probably find there is a small piece of code that
you need to optimise, then you look at whether it is written as clearly
and simply as possible for the compiler. Having made the code as simple
as you can and remeasured to check you still have a problem, and
remeasured some more to ensure the problem is still in the same place,
you then look at the assembler the compiler is producing and consider
your options.
> Because I thought there where
some general rules like:
int counter = 0;
while(counter < something)
{
do work;
counter++;
}
OR
for(int counter = 0; counter < something; counter++)
{
do work;
}
are totaly different implemented in assembly, or is this only compiler (and
its settings offcourse) dependant?
The general rule with something like that is write what will be clear
and maintainable. The compiler can, and generally will, do this kind of
transformation. If it doesn't do something that simple then look to see
if there is a better compiler you can use that will. After having
verified that you are telling the compiler to optimise the code, of course.
