[FFmpeg-devel] [PATCH] adpcm: Reset the ssd back to zero more often
Tue Nov 30 10:09:18 CET 2010
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?
More information about the ffmpeg-devel