[FFmpeg-devel] dealing with tables in DV codec

[Michael Niedermayer]

On Wed, Sep 10, 2008 at 12:26:24PM -0700, Roman Shaposhnik wrote:
> On Wed, 2008-09-10 at 08:22 +0100, M?ns Rullg?rd wrote:
> > Diego Biurrun <diego at biurrun.de> writes:
> > 
> > > On Tue, Sep 09, 2008 at 01:51:06PM -0700, Roman Shaposhnik wrote:
> > >> 
> > >> as I promised, I tried to come with alternative ways of dealing
> > >> with macroblock placement in DV codec, and it seems that no
> > >> matter what I use on Xeon and Opteron it is basically a toss up.
> > >> There's no speed gain, there's no speed loss. The tables can
> > >> go so it is a net gain. Now, on SPARC I see a stable speed 
> > >> loss of about ~3% or so. And I suspect that the same will
> > >> be true on any chip with a low clock speed.
> > >> 
> > >> Now, I'm publishing a temporary diff to solicit public comments
> > >> on how the calculations can be optimized even further. If nobody
> > >> comes up with any kind of good ideas -- I don't know what to do.
> > >> Michale has always told us that even ~3% is significant enough. 
> > >> So it needs to be dealt with before any change can occur.
> > >
> > > I don't think SPARC is important.  Let me know what I will have to do
> > > and I will benchmark on my trusty old K6-III 500.  Then you will have
> > > numbers for a low clock speed x86 system.
> > 
> > Who gets to decide which machines are important?  Is K6-3 more
> > important than SPARC?
> 
> Thanks for saying this. On one hand Michael uses embedded systems
> as a constant argument in favor of optimizing for such
> platforms, but on the other hand there's a clear x86 tilt
> that I see. 

/me cleans romans glasses.

I suggest you ask balatoni denes about how easy it was to get a half optimal
sparc vis idct into ffmpeg.

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080910/3d9845cc/attachment.pgp>