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

[Reimar Döffinger]

On Wed, Mar 06, 2013 at 08:06:23PM +0100, "René J.V. Bertin" wrote:
> On Mar 06, 2013, at 19:40, Nicolas George wrote:
> 
> >> IMHO size_t is perfect for counters that cannot go negative.
> > 
> > For counters that can not go negative, you need an unsigned type; size_t is
> > unsigned all right, but it is far from being the only one.
> > 
> > The problem with size_t is that it has a different size depending on the
> > architecture: your program will seem to work great on your x86_64 and may
> > fail on a x86_32.
> > 
> > size_t is for the size of objects in memory, because it is directly linked
> > to the limitations of the architectures.
> > 
> > For integers that need to handle large values, ffmpeg use (u)int64_t.
> 
> Agreed, the thing is that I'm not sure uint32_t is likely to flow over ... unless on a VERY fast machine on which the wait will be tolerable (I can't really imagine running benchmarks that take forever) ... and that machine will probably have size_t defined as at least uint64_t .
> Using 64 bit integers on 32 bit hardware (or in 32 bit mode) gives a performance hit except (AFAIK) on the PowerPC G5 .

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.
Making behaviour depend on the machine type is certainly a lot worse.
Also to be pedantic x32 will have 32 bit size_t but fast 64 bit
operations (not that I think x32 is worth caring about).

> > thanksForFixingItButIAssureYouThatCamelCaseIsInherentlyUglyJustConsider
> > HowPainfulItWasToReadThisSentenceSpacesWereInventedForAGoodReason.
> 
> Using_variable_or_function_names_with_such_long_names_is_just_as_bad_an_idea_and_certainly_not_prettier_written_like_this :P

I find it vastly more easy to read though. The difference between space
and _ is quite minimal.