[FFmpeg-devel] [PATCH] adpcm: Reset the ssd back to zero more often
Michael Niedermayer
michaelni
Wed Dec 1 03:45:09 CET 2010
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>
More information about the ffmpeg-devel
mailing list