[FFmpeg-devel] a new benchmarking option for ffmpeg - patch 1 of 2

"René J.V. Bertin" rjvbertin at gmail.com
Thu Mar 7 10:16:10 CET 2013


On Mar 06, 2013, at 20:36, Reimar Döffinger wrote:

> For most operations that's an additional instruction, I can't imagine
> you will be able to measure the difference since we're not talking
> about code in an inner loop here.

You're probably right, I mentioned the performance benefit only out of principle (minimising the perturbance of the measuring routine on the measured routine).
That said, I do remember that compiling for 32 bit with -mpowerpc64 (gcc option) on the G5 gave a small but consistent gain. Of course that caused *all* operations on 64 bit (integer) data to be executed in 64 bit mode. I wasn't aware x32 did something similar, in fact I thought gcc didn't have a mpowerpc64 equivalent for i386 because the hardware didn't support it.

> Making behaviour depend on the machine type is certainly a lot worse.

Not to be splitting hairs, but the only thing that depends on machine type here is the wrap-around moment. Using uin64_t there will also be a wrap-around ... and I doubt the limit is likely to be reached in the usual scenarios. Certainly not for video, where a sample corresponds to a frame (and 4294967295 frames would make a rather huge/loooong sequence). Maybe for audio, and even then the limit will be hit first in the cumulative bin.

Of course I may be mistaken in this, and in that case I probably ought to implement either a warning ... or promote the counters to double (which ought not make a difference on the printed results)?

R


More information about the ffmpeg-devel mailing list