[XviD-devel] XViD Profiling Measured time != Overall time

[sajid anwar]

Infact first I didnot change any thing and just used the existing xvid code
for profiling. The earlier email is about this and the results are neither
cosistent (some times it says VLD has spent 19 % time and some times it says
14%) and nor complete. Infact my point is like this;

                                            *start_global_timer*
                                                    .[start_timer ---
stop_timer] // both XViD and later my own custom defined
                                                    .[start_timer ---
stop_timer]
                                                    .[start_timer ---
stop_timer]
                                            *stop_global_timer*

The time measured in the above internals the global timers overall time !=
sum of xxxx timers. This is true even if I define a start_Ivop_timer and
stop_Pvop_timer, then sum them and compare with overall time.







On Wed, Dec 17, 2008 at 11:03 PM, Dark Sylinc <dark_sylinc at yahoo.com.ar>wrote:

> > Overall encoding time: 140.000000 ms, we measured 40.000000
> > ms (28.571429
> > percent) Or
> >
> > Overall encoding time: 160.000000 ms, we measured
> > 100.000000 ms (62.500000
> > percent) and never ever is the measured time equal to the
> > overall time.
>
> I'm confused "how" you measured it your self.
>
> > Overall encoding time: 140.000000 ms,
> > Overall encoding time: 160.000000 ms
> 20 milliseconds difference between 2 tests seems reasonable.
> (a 14% increase)
>
> >we measured 40.000000 ms
> >we measured 100.000000 ms
> a 250% increase in time taken seems huuughe.
> So... how are you measuring it exactly?
> Because your readings don't seem as stable as XviD's
>
>
> Last minute revision:
> ---------------------
> I've checked CVS read_counter() and get_freq() before sending the mail:
>
> 1) We're using the rdtsc for god sake!! AFAIK rdtsc gets REALLY unstable
> (unnacurate) when combined with multi-core
>
> 2) get_freq() is really unacurrate too! Again, thanks to multi-core (not
> just multi core, but any kind of multi threading, even another process may
> interrupt this) and Cool 'n Quiet feature, get_freq() may return much
> smaller values than it should, resulting in higher times.
>
> So after seeing this, I strongly feel Anwar Sajid is right.
>
> We should be using gettimeofday for UNIX variants, and
> QueryPerformanceCounter in Windows.
>
> Cheers
> Dark Sylinc
>
> IMPORTANT:
> The information contained in this email may be commercially sensitive
> and/or legally privileged. It is intended solely for the person(s) to whom
> it is addressed. If the reader of this message is not the intended
> recipient, you are on notice of its status and hereby notified that your
> access is unauthorized, and any review, dissemination, distribution,
> disclose or copying of this message including any attachments is strictly
> prohibited. Please notify the sender immediately by reply e-mail and then
> delete this message from your system.
>
>
>
>
>  ____________________________________________________________________________________
> ¡Buscá desde tu celular!
>
> Yahoo! oneSEARCH ahora está en Claro
>
> http://ar.mobile.yahoo.com/onesearch
> _______________________________________________
> Xvid-devel mailing list
> Xvid-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>