[FFmpeg-devel] [RFC] slightly "simplify" ff_ac3_bit_alloc_calc_psd

[Reimar Döffinger]

On Wed, Jan 13, 2010 at 06:20:46PM -0500, Justin Ruggles wrote:
> Reimar D?ffinger wrote:
> 
> > Hello,
> > this is one instruction less in the inner loop due to a "clever" use of
> > lea by the compiler instead of needing a cmov.
> > Might help more on machines without cmov, because on Intel Atom the
> > difference is quite unstable even with START_TIMER/STOP_TIMER.
> > Somewhat representative values (sorry, the numbers I got were
> > all next to useless):
> > new:
> > 30846 dezicycles in calc_psd, 65501 runs, 35 skips
> > old:
> > 31299 dezicycles in calc_psd, 65496 runs, 40 skips
> > 
> > Index: libavcodec/ac3.c
> > ===================================================================
> > --- libavcodec/ac3.c	(revision 21191)
> > +++ libavcodec/ac3.c	(working copy)
> > @@ -112,9 +112,10 @@
> >          int v = psd[bin++];
> >          int band_end = FFMIN(band_start_tab[band+1], end);
> >          for (; bin < band_end; bin++) {
> > +            int max = FFMAX(v, psd[bin]);
> >              /* logadd */
> > -            int adr = FFMIN(FFABS(v - psd[bin]) >> 1, 255);
> > -            v = FFMAX(v, psd[bin]) + ff_ac3_log_add_tab[adr];
> > +            int adr = FFMIN(max - ((v + psd[bin] + 1) >> 1), 255);
> > +            v = max + ff_ac3_log_add_tab[adr];
> >          }
> >          band_psd[band++] = v;
> >      } while (end > band_start_tab[band]);
> 
> ok, as long as they are mathematically equivalent, which appears to be
> the case at first glance.

Assuming that no overflows happen in either one (of which I am quite certain),
yes.
Too bad the rounding is that way, would have been much nicer if the + 1 wasn't
necessary.
Anyway, applied.