[FFmpeg-devel] [PATCH] ff_scalarproduct_float_sse

Reimar Döffinger Reimar.Doeffinger
Wed Jan 20 22:26:25 CET 2010


On Wed, Jan 20, 2010 at 01:06:00PM -0800, Jason Garrett-Glaser wrote:
> On Wed, Jan 20, 2010 at 12:58 PM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > On Wed, Jan 20, 2010 at 03:43:23PM -0500, David Conrad wrote:
> >> On Jan 20, 2010, at 9:19 AM, Michael Niedermayer wrote:
> >>
> >> > On Tue, Jan 19, 2010 at 11:42:40PM -0500, Alex Converse wrote:
> >> >> This cause a >50% decrease in SBR decode time.
> >> >>
> >> >> For the time being it can help in the other places where
> >> >> scalarproduct_float() is used.
> >> >>
> >> >> Regards,
> >> >> Alex Converse
> >> >
> >> >> dsputil_mmx.c ? ?| ? ?5 +++++
> >> >> dsputil_yasm.asm | ? 25 +++++++++++++++++++++++++
> >> >
> >> > Would you mind to avoid yasm and use gcc asm instead ?
> >> >
> >> > I have no problem with yasm as such but gcc asm is more portable and
> >> > can be integrated with C code if we ever want that.
> >>
> >> I'd argue that it's less portable given that the majority of the compiler bugs I've encountered stem from inline asm. In fact, right now llvm svn trips on two separate inline asm bugs on x86-32, and llvm-gcc on another on x86-64. And gcc-4.2 and later have several silent miscompilations and register allocation failure with inline asm on x86-32 OS X when using PIC.
> >
> > Less maintenance effort probably, but not more portable by my definition of it.
> > Last time we discussed it at least it didn't work e.g. on OS/2.
> > And it's always something that doesn't come with the system. I just realized I've
> > been doing my last Windows builds of FFmpeg and MPlayer without yasm because I
> > forgot to install it...
> 
> "Doesn't work on OS/2" is better than "doesn't work on 2/3 of targets
> because GCC doesn't like the phase of the moon".

Well, IMO one is about portability and the other one is more about working
well in general.
Personally I actually care more about the "user doesn't have to install yasm"
part, but I realize it doesn't make for a convincing argument objectively.



More information about the ffmpeg-devel mailing list