On Wed, 2016-06-22 at 21:02 +0000, Carl Eugen Hoyos wrote: > Dan Parrot <dan.parrot <at> mail.com> writes: > > > Could I get a yes or no answer on whether the patch will be applied? > > Please comment on my email: time make fate can be used to show > large performance changes (although it isn't optimal), I don't > think it can show the difference between a division and a shift.
I was not trying to show the difference in relative cost between a division and a shift using "time make fate". What I was trying to show is that ffmpeg compiled with code that uses the division versus ffmpeg compiled with code that uses shifts resulted in running times for fate that were essentially equal. Now, if you want me to demonstrate the relative speeds of the division and shift, I can do that. I admit to not seeing the point in the exercise, but if that is what is holding up patch acceptance, I will do it. And yes, the "time" utility is imperfect, but so is any technique which does not turn off all hardware interrupts in order to guarantee that the code being timed runs to completion without ever being paused. The goal of Trac ticket #5570 as best I understand it is to use SIMD hardware on PPC64 to reduce execution time of the functions in libswscale/input.c. Right? So, the comparison we should be talking about is whether ffmpeg currently in the repository is faster/slower than ffmpeg compiled using the patch. Timing fate suite when run with the two different versions of ffmpeg should be an acceptable indicator of which is faster. If I mistaken in any of the above, I am always willing to learn. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
