Re: pointer movement?

["DuckE" <nospam_steved94@home.com>]

I agree it is not a good idea to have roaming pointers.  And go a step
farther to preach my version of the rules of optimization (they're not
orginal but I can't remember the source):
  Rule #1.  Don't do it.
  Rule #2.  Don't do it yet.
  Rule #3.  Only optimize those parts of the program that need optimization.
With the side not that typically 10% of the program runs 90% of the time.

But...
  In my experience using GCC on an MVME162 (MC68040) under VxWorks, when I
had to optimize certain time critical parts of code (a very small fraction
of the overall code in the system), I found that sequencing through memory
by incrementing pointers was somewhat faster than incrementing an array
index and accessing the same memory by indexing the array.

IMHO it is not obvious that either method would perform better.  The only
way to determine performance is through testing or detailed analysis of the
generated code on the specific target architecture.

Generally you are better off to write the code in an obvious manner and
trust the compiler to be smarter than you are at generating optimal code
(compilers often are).  But when push comes to shove and you find that you
are close to but not quite achieving the required performance, in some cases
re-arranging the code will help.

SteveD

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111171819.d56766d@posting.google.com...
[snip]
>
> It is a fallacy that having roaming pointers C style
> will improve efficiency. In fact, this sloppy use of
> pointers often makes it impossible for a C compiler
> to do proper aliasing analysis. Declare an array,
> reference it in the obvious manner, and for the most
> typical code, normal optimizations should bring you
> back to at least the C code efficiency, and if you use
> a compiler with good aliasing analysis, perhaps better.