Re: command.c: gm benchmark iterations and duration

Bob Friesenhahn <[email protected]> Thu, 28 Aug 2008 22:56:33 -0500 (CDT)
Newsgroups gmane.comp.video.graphicsmagick.core
Message-ID <[email protected]>
On Fri, 29 Aug 2008, Nguyen Vu Hung wrote:
> portable> timer resolution is often not very good.  For example, 
> Windows only> offers 20ms granularity.  Many Unix systems offer 
> 10ms, but some could> be as terrible as 100ms since the traditional 
> Unix clock tick is> 100Hz.  The "user time" measurement is often 
> based on if the process> used CPU in one of those 100Hz scheduling 
> intervals.  The possibility> of poor timer resolution is a reason 
> for running the benchmark for> tens of seconds rather than a few 
> iterations or just a second.

> Nowadays, most modern CPUs do have much more faster clock.
> Even a quite old PC using Pentium IV 2.4GHz is 24 times faster then 
> the CPU you have mentioned.

By "Unix clock tick" I am talking about the process scheduler clock 
tick.  This is the maximum time a process will be allowed to use the 
CPU before the process scheduler intervenes to see if there is a 
process more worthy to run.  Normally this is 100Hz but some OSs allow 
it to be set to 1000Hz.  The Unix clock tick interval is important 
since it is the resolution offered when measuring "user time".

> We don't have to worry about CPUs in embedded systems as well.As far 
> as I know, most recent PDAs have CPU faster clocks faster than 
> 400MHz.

The CPU clock rate is not important since this is not (usually) the 
clock which is used to keep time.  Most modern CPUs use variable 
internal clock rates in order to save energy.  There is a clock device 
which deliveres a periodic clock interrupt to the kernel.

> There are two approaches to benchmark:

> 1. Benchmark a block of code( gm benchmark uses this )2. Benchmark a 
> whole run of a application( for example "time gm convert in out)

> The first approach is good for those who uses GM as a native 
> library,while the later is used by those who runs GM from command 
> line, orfrom a script.

Yes.  Decreasing overall run time can be challenging since the 
bottleneck might be disk I/O.  But more CPU efficiency leaves more CPU 
available for other tasks.

Bob
======================================
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/