On Fri, Jan 22, 2016 at 05:54:30PM +0000, John Cox wrote: > Hi > > >Hi, > > > >2016-01-22 14:29 GMT+01:00 John Cox <j...@kynesim.co.uk>: > >>>This is a big slowdown on Win64 and UHD-bluray like sequences, but > >>>that can be switched off in that case. > >> > >> I'm a bit surprised that it generated a big slowdown - some cache must > >> be running just on the edge, but yes if you normally have hi-bitrate > >> stuff then it isn't wanted. On my test streams the bitrates were > >> normally quite low - quite unlike what I would expect from blu-ray > >> sequences. > > > >Initial (4 sequences): > > 6553 decicycles in g, 8387110 runs, 1498 skips > > 5916 decicycles in g,33546118 runs, 8314 skips > > 5028 decicycles in g,67101499 runs, 7365 skips > > 4729 decicycles in g,33548420 runs, 6012 skips > > > >Deactivating USE_N_END_1: > > 4746 decicycles in g,16774296 runs, 2920 skips > > 5373 decicycles in g,33545629 runs, 8803 skips > > 4141 decicycles in g,67098928 runs, 9936 skips > > 3869 decicycles in g,33544593 runs, 9839 skips > > > >But I see the first one surprisingly having half the iterations (but > >this has almost converged at this point). > >So 10-20%. > > Coo - that is big. > How are you profiling that and with what streams?
seems this question was missed the stuff above used START/STOP_TIMER() i assume i dont know which streams where used > > >I think it has more to do with cache pressure, both code, which > >increases from 8 to 9.5KB, and data, with already "large" tables in a > >loop that may need to tight. > > I agreee (and it is what I was trying to suggest in my previous > comment). It also suggests that on x86 you might benefit from > non-inlined cabac_gets to keep the code size small. > > >> Default it to off on x86 but on on ARM? > > > >Yes, I think so. > Is ARCH_X86/ARM an appropriate switch for this? yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
