[Ffmpeg-devel] [PATCH] fix mpeg4 lowres chroma bug and increase h264/mpeg4 MC speed
Tue Feb 13 02:53:38 CET 2007
On Mon, 12 Feb 2007, Michael Niedermayer wrote:
> On Mon, Feb 12, 2007 at 12:49:30PM +0100, Michael Niedermayer wrote:
> > > > > Why do you discard some times in your TIMER code? Is the goal just to
> > > > > discard those times in which an interrupt occured?
> > > >
> > > > yes
> > >
> > > That's not what's is doing, there are far too many skips for that to
> > > be the case.
> > indeed ill try to improve START/STOP_TIMER
> the new code will never skip if the code needed <2000 cycles,
> interrupts on the 2 systems i tested need >5000 cycles so thats
> a slight improvment, all other things ive tried failed (that was
> reading and comparing /proc/interrupts (reading this itself causes
> interrupts (about 10000 per second ...))
> comparing clock() or related functions only catch 10% of the intrrupts
> comparing getrusage() still catches only 50% of the interrupts
> if anyone has any ideas how we could detect if a interrupt/task switch
> happened between START and STOP_TIMER please tell me ...
You could use the performance monitoring counters. One of the things
you're allowed to count is in the number of hardware interrupts. These are
no so simple to use as rdtsc. The are model specific, and need a certain
amount of OS support. But it is possible to just execute an rdpmc
instruction and find out how many interrupts have occurred.
Or have the OS set a flag in readable memory somewhere when an interrupt
occurs. Clear the flag at the start of your code, and if it's set at the
end an interrupt occured. Not sure how that would work with SMP...
Is your goal to find the true speed (peak? average?) at which some code
runs? Or is your goal to compare different ways of doing something and say
which one is faster?
If it's the latter, then I wouldn't worry about catching interrupts. Some
calls of the code will get an interrupt and have too many cycles. Most of
the calls won't. The interrupts will add a very small amount of error to
your average cycle count. That's ok. All measurements in all fields of
science have error!
One run of one version of code will have some error from interrupts. The
next run will have a different amount of error. The other version of the
code will have error too when it's benchmarked. This is why you run the
benchmarks many times. Then you can use statistics to make mathematically
precise statements about the confidence of one version being faster than
another despite the presence of measurement error. If difference between
versions is so small and the error so large that the error overshadows the
difference, then statistics will tell you that you can't say which is
faster with much confidence. That's probably a good sign you're wasting
your optimization efforts trying to decide which version to use.
More information about the ffmpeg-devel