caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Quôc Peyrot" <chojin@lrde.epita.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Re: Execution time of class versus record
Date: Tue, 26 Jun 2007 18:29:28 +0200	[thread overview]
Message-ID: <D8E5B9FF-7A13-4F3A-8360-E4E963B25783@lrde.epita.fr> (raw)
In-Reply-To: <46811608.5080707@gnu.org>


On Jun 26, 2007, at 3:35 PM, Sam Steingold wrote:

>> Please, knows someone what I'm doing wrong?
>>  let t0 = Unix.gettimeofday () in
>>  Printf.printf "elapsed = %f\n" (Unix.gettimeofday() -. t0)
>
> Unix.gettimeofday is "wall clock".
> Unix.times is "CPU time".
> use the latter to time your programs because the former depends on the
> machine load at the time of the test while the latter does not.

In my experience, you need both.

Thread locks, NFS latency, load and so on can indeed impact the wall  
clock
but it is ultimately what the customers are seeing. If you don't  
measure it,
you might be missing bugs or possible IO optimizations. Some code might
be looking perfectly fine in CPU time, but be catastrophic in real  
wall clock
due to various reasons.

But you also need the CPU Time to make sense of the wall clock time.
Once a slow part of the code is identified (using wall clock) and once
load or IO problems have been ruled out, it's good to use the CPU
time to measure any optimizations done.

What I meant is:
- most of the time, if the machine is not really overloaded CPU Time  
~= wall clock
   In this case, it's good to only look at the CPU Time
- If you see that overall, on all the measures in all parts of the  
program there is
   a huge difference between CPU and wall clock, then it is probably  
a general
   load problem
- But, you might see a huge difference only in certain part of the  
program,
   in such cases, it should be investigated.

If you only measure wall clock, or CPU Time, you might just miss some  
part
of the big picture.

My 2 cents

-- 
Best Regards,
Quôc




  reply	other threads:[~2007-06-26 16:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-24 15:14 tmp123
2007-06-24 15:29 ` [Caml-list] " Jon Harrop
2007-06-24 15:48   ` Till Varoquaux
2007-06-24 16:06     ` Arnaud Spiwack
2007-06-24 18:18       ` skaller
2007-06-24 18:29       ` Gerd Stolpmann
2007-06-24 18:51         ` Arnaud Spiwack
2007-06-24 19:11           ` Chris King
2007-06-25  3:25           ` Jon Harrop
2007-06-25 11:16             ` Arnaud Spiwack
2007-06-25 12:07               ` Jon Harrop
2007-06-25 23:59                 ` Jonathan Bryant
2007-06-26  0:15                   ` Chris King
2007-06-26  6:53                     ` Loup Vaillant
2007-06-26  7:02                       ` Jon Harrop
2007-06-26 17:07                         ` Loup Vaillant
2007-06-28  1:13                 ` Christian Stork
2007-06-26 13:35 ` Sam Steingold
2007-06-26 16:29   ` Quôc Peyrot [this message]
     [not found] <20070626065522.6175FBC77@yquem.inria.fr>
2007-06-26  7:36 ` David Allsopp
2007-06-26  8:05   ` [Caml-list] " Nicolas Pouillard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D8E5B9FF-7A13-4F3A-8360-E4E963B25783@lrde.epita.fr \
    --to=chojin@lrde.epita.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).