> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Lynne > Sent: Tuesday, January 12, 2021 9:47 PM > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Add support for "omp simd" pragma. > > Jan 12, 2021, 19:28 by reimar.doeffin...@gmx.de: > > >> > >> On 10 Jan 2021, at 19:55, Lynne <d...@lynne.ee> wrote: > >> > >> Jan 10, 2021, 17:43 by reimar.doeffin...@gmx.de: > >> > >>> From: Reimar Döffinger <reimar.doeffin...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
