--- In [email protected], "mikejd42" <mikej...@...> wrote:
>
> --- In [email protected], "John Matthews" <jm5678@> wrote:
> >
> > --- In [email protected], "mikejd42" <mikejd42@> wrote:
> > >
> > > --- In [email protected], "John Matthews" <jm5678@> wrote:
> > > >
> > > >     newPixel = (pixel1 + pixel2) / 2;
> > > >
> > > instead of the "/2" use " >> 1" its faster with less overhead.
> > 
> > The compiler will generate code that effectively does >>1 to implement the 
> > /2 (if it doesn't then time to change compilers). So I would argue that 
> > it's better to write it as /2 because logically that's what you want to do.
> >
> 
> Logically you want to shift right one.

No you don't - you want to divide by 2.

> I believe it is better to think optimally and code that way than to let the 
> compiler do it.

Up to a point - but the danger is that you end up with a design which is 
optimally coded that no-one can understand, and is hence difficult to debug and 
(assuming you can get it working) maintain.

> Far too many programmers are not trained to optimize and scrutinize their 
> code.

And far too many programmers attempt to optimize their code and end up with a 
mess, instead of concentrating on a good, clear design. If there are still 
performance problems, then by all means look for areas to optimize (probably 
after running some sort of profiler).

> When you think how can I best write this to be a good steward of the machine 
> resources it becomes second nature to write a /2 as shift right one and *2 as 
> shift left one.

I target code at CPUs where I might only have 512 bytes (not kbytes) for 
program code, and have spent many man weeks trying to squeeze quarts into point 
pots, as well as hit sub-millisecond real time timing requirements. So I know 
that sometimes you have to do everything possible to optimize for code space 
and/or speed. However, you should still start off with somethings that's as 
clear as possible, and I don't believe using bit shifts for arithmetic meets 
that criteria.

I guess we'll just have to agree to disagree :-)

Reply via email to