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? >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? Regards JC _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
