> > 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. > 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. > Most of the loops this is added to are trivially SIMDable. How many hours of effort do you consider “trivial”? Especially if it’s someone not experienced? It might be fairly trivial with intrinsics, however many of your counter-arguments also apply to intrinsics (and to a degree inline assembly). That’s btw not just a rhetorical question because I’m pretty sure I am not going to all the trouble to port more of the arm 32-bit assembler functions since it’s a huge PITA, and I was wondering if there was a point to even have a try with intrinsics... > Just because no one has > had the motivation to do SIMD for a pretty unpopular codec doesn't mean we > should > compromise. If you think of AArch64 specifically, I can kind of agree. However I wouldn’t say the word “compromise” is appropriate when there’s a good chance nothing better will ever come to exist. But the real point is not AArch64, that is just a very convenient test platform. The point is to raise the minimum bar. A new architecture, RISC-V for example or something else should not be stuck at scalar performance until someone actually gets around to implementing assembler optimizations. And just to be clear: I don’t actually care about HEVC, it just seemed a nice target to do some experiments. Best regards, Reimar _______________________________________________ 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".
