[FFmpeg-devel] [PATCH] adpcm: Reset the ssd back to zero more often

[Martin Storsjö]

On Sun, 21 Nov 2010, Martin Storsj? wrote:

> On Sun, 21 Nov 2010, Michael Niedermayer wrote:
> 
> > On Sun, Nov 21, 2010 at 01:11:12AM +0200, Martin Storsj? wrote:
> > > On Sat, 20 Nov 2010, Michael Niedermayer wrote:
> > > 
> > > > On Sat, Nov 20, 2010 at 08:59:25AM +0200, Martin Storsj? wrote:
> > > > > On Sat, 20 Nov 2010, Michael Niedermayer wrote:
> > > > > 
> > > > > > On Thu, Nov 18, 2010 at 04:01:31PM +0200, Martin Storsjo wrote:
> > > > > > > If using very large trellis sizes (e.g. -trellis 15), the frontier
> > > > > > > is so large that the difference between the best and the worst
> > > > > > > trellis node in the frontier is large enough to cause wraparound.
> > > > > > > 
> > > > > > 
> > > > > > > Resetting at (1<<20) is enough to avoid the issue at -trellis 16
> > > > > > 
> > > > > > have you come to this conclusion by proof or by simply changing the
> > > > > > threshold and seeing no problems?
> > > > > 
> > > > > By changing the threshold until there were no more problems with that 
> > > > > particular sample - sorry, I should have mentioned that.
> > > > > 
> > > > > I think it can't be proven how often it needs to be reset. In the worst 
> > > > > pathological case, the best trellis node has ssd 0 while the worst one has 
> > > > > a ssd of 65535*65535 added in each generation, overflowing even if we'd 
> > > > > subtract the best node's ssd each round.
> > > > > 
> > > > > The attached patch should avoid the issue properly regardless of how 
> > > > > pathologically bad case it is, giving a small but tolerable slowdown. Do 
> > > > > you think that is enough, or should that one be combined with this 
> > > > > previous patch, resetting it to 0 more often (or perhaps even every round) 
> > > > > to avoid this issue happening at all?
> > > > 
> > > > have you tried to change ssd to 64bit ?
> > > > maybe its faster
> > > 
> > > In 64 bit mode, changing ssd to 64 bit is a bit faster (current code 61 
> > > sec, adding the wraparound check 64 sec, 64 bit ssd 62 sec), but in 32 bit 
> > > mode, it's quite a bit slower (current code 69.6 sec, with wraparound 
> > > check 69.8 sec, 64 bit ssd 79.6 sec), so I wouldn't suggest that solution.
> > 
> > 70->80sec hmm, did you look at the generated code?
> 
> No, I'm not familiar enough with x86 asm to be able to say whether the 
> compiler is messing up or not.
> 
> But I tested these changes on a few other compiler versions (on other 
> machines), running in 32 bit mode:
> gcc 4.0: current: 68 sec, wraparound check: 66 sec, 64 bit ssd: 73 sec
> gcc 4.1: current: 67 sec, wraparound check: 71 sec, 64 bit ssd: 74 sec
> gcc 4.4: current: 83 sec, wraparound check: 89 sec, 64 bit ssd: 96 sec

Here I forgot to clarify - the earlier initial benchmarks were done with 
gcc 4.2.

// Martin