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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101201/18ae12e6/attachment.pgp>