[Mplayer-cvslog] CVS: main/mp3lib decode_MMX.c,1.8,1.9

[Felix Buenemann]

On Monday 27 October 2003 21:03, D Richard Felker III wrote:
> On Mon, Oct 27, 2003 at 10:44:56AM +0100, Arpi wrote:
> > Hi,
> >
> > > > > > > reverting my last change as buggy gcc 3.x fails with it :(
> > > > > >
> > > > > > gcc addresses local variables by ebp or esp, and push/pop change
> > > > > > esp so it cant work (the correct solution would be to make some
> > > > > > free space manually on the stack and use that instead)
> > > > >
> > > > > Strange is that it worked on 2.95.x
> > > > >
> > > > > Actually the whole code could be rewritten..it's crappy
> > > >
> > > > Actually optims should be ported/redone for ffmp3 and finally rm -rf
> > > > mp3lib its just broken in many ways, not worth to fix.
> > >
> > > I'm no mp3lib fan either, but keep in mind that it is still a lot
> > > faster on older systems (eg. Pentium II. tested that recently).
> >
> > It's still a lot faster on any x86 systems, maybe on others too.
> > I was trying to find bottlenecks of ffmp3, and optimize it but failed.
> > The 3 most critical functions of ffmp3:
> >   compute_antialias
> >   compute_imdct
> >   synth_fv
> >
> > they are slow for 2 reasons:
> > - no SIMD optims at all
> > - uses integer (fixedpoint) only, which seems to be slower on intel x86
> > than float
>
> Reason 2 is nonsense. On slower x86 (Pentium, K6, ...), integer is
> MUCH MUCH faster than float! And slower systems are the only ones
> where mp3 decoding time matters...
Anyways, mp3lib even contains handcoded fpu assembler code, so probably that's 
the reason.

> Rich

-- 
Best Regards,
        Atmos
____________________________________________
- MPlayer Developer - http://mplayerhq.hu/ -
____________________________________________