On Tue, May 24, 2016 at 04:10:07PM -0400, Ronald S. Bultje wrote: > Hi, > > On Tue, May 24, 2016 at 3:47 PM, Luca Barbato <lu_z...@gentoo.org> wrote: > > > On 23/05/16 17:01, Ronald S. Bultje wrote: > > > Howdy, > > > > Interesting. I spent a bit of time on it myself. > > > > I run some benchmark using a yuv422 file of the right size from the > > Tim's collection [directly][1] and looped/cut to have a length that > > works fine (1minute and 10 minutes) and I used `perf stat -r 30` on a > > system that surely has a cpu unencumbered by random process on a server, > > so it does not have random quirks like a laptop one. > > > > The benchmark shown that force-inlining bitstream_read_vlc is not > > exactly helpful on the poor constained x86_32, and its implementation > > could spare few branches. > > > > With that change in, looks like the gains for x86_64 get even larger. > > > > I get the dnxhd to be about 3% slower on x86_32 and 20% faster on x86_64. > > [..] > > > And with that I guess we are set =) > > > But 2 out of 3 are still slower. I can try to look somewhat more into this, > but I think that not understanding what makes it slower is fundamentally > flawed.
So you admit you're fundamentally flawed? Sane approach would be to study proper performance tools output, like perf on Linux. Or look at generated assembly and referring to instruction timings and latencies if one wants it hardcore way. > If we understand why it's slower and we decide that that's OK, > that's an entirely different thing. Is that royal we or "we, FFmpeg developers"? I'm pretty sure nobody has elected you Libav leader. _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
