[XviD-devel] XViD Profiling Measured time != Overall time
dark_sylinc at yahoo.com.ar
Wed Dec 17 15:03:02 CET 2008
> 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.
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
More information about the Xvid-devel