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

[Martin Storsjö]

On Wed, 1 Dec 2010, Michael Niedermayer wrote:

> On Tue, Nov 30, 2010 at 11:09:18AM +0200, Martin Storsj? wrote:
> > On Fri, 26 Nov 2010, Martin Storsj? wrote:
> > 
> > > On Tue, 23 Nov 2010, Michael Niedermayer wrote:
> > > 
> > > > On Mon, Nov 22, 2010 at 10:45:29AM +0200, Martin Storsj? wrote:
> > > > > On Mon, 22 Nov 2010, Michael Niedermayer wrote:
> > > > > 
> > > > > > what if this is always performed and the subtraction added into some existing
> > > > > > code.
> > > > > 
> > > > > Even if doing this each round, that doesn't help when the SSD of the 
> > > > > best node is much much smaller than the SSD of the worst node, since we 
> > > > > can't ever subtract more than the SSD of the best one. Theoretically, the 
> > > > > SSD of the best one could be at near-zero all the time, and the worst one 
> > > > > could get an added 65535^2 each round, overflowing almost instantly, while 
> > > > > there isn't anything that could be subtracted from all nodes.
> > > > 
> > > > someone could try to write asm macros for doing 64 add and compare on x86-32
> > > > especially as a proof of concept this should be quite trivial and if that
> > > > isnt slower thrn gcc likely messed up the 64bit code
> > > 
> > > Ok, I know next to nothing about inline assembly, but this seems to work 
> > > at least. I didn't do the functions as proper macros, only as inline proof 
> > > of concept, since the comparison asm requires labels for jumping.
> > > 
> > > In the following patch set, patch #1 changes the ssd variables from 32 bit 
> > > to 64 bit. Runtime goes from 69.6 to 81.25 seconds.
> > > 
> > > Patch #2 replaces the 64 + 32 bit addition with inline asm. Runtime drops 
> > > from 81.25 to 79.50 seconds.
> > > 
> > > Patch #3 replaces the 64 bit comparison with inline asm. Runtime increases 
> > > to 81.75 seconds.
> > > 
> > > So I guess patch #3 could be done in a better way, but still, this seems 
> > > to be quite a bit slower. As comparison, the version with an explicit 
> > > check runs at 69.7 seconds - almost no slowdown at all. (In 64 bit mode, 
> > > the slowdown was slightly larger but still not bad, 61 to 64 seconds.)
> > 
> > Ping - any conclusion on how to move forward with this?
> 
> pick the fastest
> that is IIRC the wraparound check
> and add a note that this has not been fully investigated and that 64bit would
> be more ideal but slower on 32bit

Applied with a comment saying that 64 bit would be better, but is slower 
currently.

// Martin