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

[Martin Storsjö]

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?

// Martin