[FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Lynne
> Sent: Tuesday, January 12, 2021 9:47 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma.
> 
> Jan 12, 2021, 19:28 by Reimar.Doeffinger at gmx.de:
> 
> >>
> >> On 10 Jan 2021, at 19:55, Lynne <dev at lynne.ee> wrote:
> >>
> >> Jan 10, 2021, 17:43 by Reimar.Doeffinger at gmx.de:
> >>
> >>> From: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> >>>
> >>> real    0m15.040s
> >>> user    0m18.874s (80.7% of original)
> >>> sys     0m0.168s
> >>>
> >>
> >> I think I have to disagree.
> >> The performance gains are marginal,
> >>
> >
> > It’s almost 20%. At least for this combination of codec and stream a
> > large amount of time is spend in non-DSP functions, so even
> > hand-written assembler won’t give you huge gains.
> >
> It's non-guaranteed 20% on a single system. It could change, and it could very
> well mess up like gcc does with autovectorization, which we still explicitly
> disable because FATE fails (-fno-tree-vectorize, and I was the one who sent
> an RFC to try to undo it somewhat recently. Even though it was an RFC the
> reaction from devs was quite cold).

I wonder whether there's a way to enable autovectorization only for 
specific loops? But that would probably be compiler-specific.

> >> its definitely something the compiler should be able to decide on its
> >> own,
> >>
> >
> > So you object to unlikely() macros as well?
> > It’s really just giving the compiler a hint it should try, though I
> > admit the configure part makes it look otherwise.
> >
> I'm more against the macro and changes to the code itself. If you can make it
> work without adding a macro to individual loops or the likes of
> av_cold/av_hot or any other changes to the code, I'll be more welcoming.
> I really _hate_ compiler hints. Take a look at the upipe source code to see
> what a cthulian monstrosity made of hint flags looks like. Every single branch
> had a cold/hot macro and it was the project's coding style. It's completely
> irredeemable.

OpenMP is a standard at least, which is supported by many compilers and
#pragma omp simd is not really a "monstrosity".


> >> Most of the loops this is added to are trivially SIMDable.

Could you provide some examples? What constructs would you suggest, 
that can be applied trivially? And that it would be compiled as SIMD even
though fno-tree-vectorize is set? 

Thanks,
softworkz