[FFmpeg-devel] [PATCH] ff_scalarproduct_float_sse
Wed Jan 20 22:06:00 CET 2010
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".
More information about the ffmpeg-devel