🚀 go-pugleaf

klamer@mi.el.utwente.nl (Klamer Schutte) writes:

>In <ben.714157437@galaxy> ben@ph.tn.tudelft.nl (Ben Verwer) writes:

>A problem with using a linear array is present when multiplication is
>slower as pointer indirection (for instance, on a sparc, or a 68000).
>Accessing image pixel (x,y) will involve accessing image[y*xsize+x];
>otherwise *(imageptr[y]+x) is used.

This is false. Or misleading. You do not need to muliply to get
to a point. Once you have set a pointer to it, increments will do.
Only when you do random acces to the image you are right.

>>The loop I most often use is:

>>pixel *p = beginofdata;
>>int i;  /* make sure this is 32 bits! */

>>for (i=xsize*ysize; --i>=0;) *p++ = ...;

>>This is the fastest on 68000Us! And also on sparcstations. Try it. (thanx to 
>>Gert van Antwerpen)

>It is not on sparcstations (and i doubt it on 68k). Faster is:

>pixel *p_end = beginofdata+sizeofdata+1;

I think you have a +1 too much.

>for(p=beginofdata;p<p_end;) *p++ = ...;
>(At least with /bin/cc and Sun C 1.4. gcc 2.2.1 didn't care...)

I don't get a difference between the following two:
for (p=start; p<end;) *p++ = 1;  /* end = start + leng */
for (i=leng; --i>=0;) *p++ = 1;
And it reads a lot better.

>Don't read that program. Above principles are not correct applied!
>(i.e. lot of looping with pointer[index] instead of *pointer++ ! )
>Also statements which are in the loop can be easily placed outside!

Through, but only the innerloop is important. 
And as you see, the principles are applied there.
(Although I agree the x=0; x<xend; x++ should be x=xend; --x>=0;
but It was written for a compiler on a vector machine which only
recognized the x=0; x<end; x++ type, sorry about that)
The little loop to fill the filter and the final copying of the result
take about .1 % of the total filter time.
Why don't you spend a few hours to see if you can get it back to
.05%. I'am sure lots of people will be interested. :)

>Klamer

Ben