On Mon, Dec 24, 2018 at 05:44:26PM +0100, Paul B Mahol wrote: > On 12/24/18, Michael Niedermayer <mich...@niedermayer.cc> wrote: > > Fixes: Timeout > > Fixes: > > 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > > --- > > libavcodec/utils.c | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > Ugly, set first row and use memcpy for rest of rows.
That would increase the load on the data cache
memcpy has to read the line each time and write it each time
otherwise the code just writes the line.
This should become especially noticable if something else accesses
the data cache like a 2nd core/thread
with just a single thread mempcpy is faster than this simple method
a slightly more complex implementation beats memcpy even single thread
though (at least in my quick test here)
of course if people prefer memcpy() (because its simpler) i can do that
what is preferred ?
code as in the patch ?
memcpy ?
even more messy but slightly beating memcpy ?
(i have to actually clean this up and retest as it does a aliasing violation
if people want this one)
and of course there are more options like with asm to implement that
memcpy:
5585847 decicycles in A, 4 runs, 0 skips
ugly:
5696222 decicycles in A, 4 runs, 0 skips
ugly and messy:
5527612 decicycles in A, 4 runs, 0 skips
original:
14953532 decicycles in A, 4 runs, 0 skips
tested with: fate-suite//h264/SonyXAVC_LongGOP_green_pixelation_early_Frames.MXF
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
