comp.lang.ada
 help / color / mirror / Atom feed
From: "John R. Strohm" <strohm@airmail.net>
Subject: Re: pointer movement?
Date: Mon, 19 Nov 2001 07:05:56 -0600
Date: 2001-11-19T07:05:56-06:00	[thread overview]
Message-ID: <0232EB9B71AA469C.63E4D85432274436.A56779B689231DC6@lp.airnews.net> (raw)
In-Reply-To: rvFJ7.41888$XJ4.23981255@news1.sttln1.wa.home.com

I *KNOW* this is a stupid question, but (a) did you look at the generated
object code (b) keeping in mind the organization of the memory and the
caching and the response times?

A few years ago, I was doing image processing with a TI 320C80.  The way one
walked through the image (row-wise vs. column-wise) made a MAJOR difference
in the raw processing speed, because the RAM arrays could access successive
locations in a "row" a LOT faster than they could access successive
locations in a "column".  Some of the processing I was doing naturally
worked on a row at a time; some naturally worked on a column at a time.  We
compromised for consistent transfer times by processing small rectangular
patches at a time.

320C80 image processing code is some of the hardest I have ever done.  You
sweat blood for months over a loop with maybe twenty or thirty source
instructions in it, because that loop HAS to touch every pixel in the frame,
and the system HAS to run at video speed.  I thank my lucky stars I got my
start on a CDC 6600 all those years ago; the mindset from 6600 programming
came in handy.

DuckE <nospam_steved94@home.com> wrote in message
news:rvFJ7.41888$XJ4.23981255@news1.sttln1.wa.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.
>
>





  reply	other threads:[~2001-11-19 13:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-17 11:39 pointer movement? Andrzej Rybczynski
2001-11-17 17:54 ` Nick Roberts
2001-11-18  2:19 ` Robert Dewar
2001-11-18  3:00   ` DuckE
2001-11-19 13:05     ` John R. Strohm [this message]
2001-11-19 15:03       ` DuckE
  -- strict thread matches above, loose matches on Subject: below --
2001-11-17 14:18 Gautier Write-only-address
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox