[Ffmpeg-devel] [PATCH] fix mpeg4 lowres chroma bug and increase h264/mpeg4 MC speed

[Michael Niedermayer]

Hi

On Mon, Feb 12, 2007 at 05:53:38PM -0800, Trent Piepho wrote:
> 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 ...
[...]
> 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...

i think requireing to modify the kernel for using START/STOP_TIMER is not a
good idea ...

rdpmc though might be worth a try ...


> 
> 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?

my goal is to compare of course, and do so quickly and without having to stop
all other applications on the system


> 
> 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!

yes and in all fields of science peoply try to reduce the errors in their
measurements ...


> 
> 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.

the problem is that errors are systematic and statistics cannot seperate them
out from a routine which just really sometimes needs much more time
think of the following example:

a routine which needs 10000 cycles per run but once in 100 runs it needs
1000000 cycles (due to some task switch and an other app doing something
or maybe it really has to deal with more complex data)
suddenly your code looks as if it needs 20000 cycles ...

the benchmark suddenly becomes dependant on the amount of cpu time
taken by other processes, this is not good ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070213/4f4291c6/attachment.pgp>