From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id BA73CBC69 for ; Tue, 26 Jun 2007 18:29:30 +0200 (CEST) Received: from smtp28.orange.fr (smtp28.orange.fr [80.12.242.100]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5QGTUwt025574 for ; Tue, 26 Jun 2007 18:29:30 +0200 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2813.orange.fr (SMTP Server) with ESMTP id 3EAF07000094 for ; Tue, 26 Jun 2007 18:29:30 +0200 (CEST) Received: from [192.168.1.162] (ALagny-153-1-81-42.w90-3.abo.wanadoo.fr [90.3.48.42]) by mwinf2813.orange.fr (SMTP Server) with ESMTP id 13F697000089 for ; Tue, 26 Jun 2007 18:29:30 +0200 (CEST) X-ME-UUID: 20070626162930818.13F697000089@mwinf2813.orange.fr Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46811608.5080707@gnu.org> References: <467E8A6E.9050700@menta.net> <46811608.5080707@gnu.org> X-Gpgmail-State: !signed Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Qu=F4c_Peyrot?= Subject: Re: [Caml-list] Re: Execution time of class versus record Date: Tue, 26 Jun 2007 18:29:28 +0200 To: caml-list@inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at concorde with ID 46813EEA.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lrde:01 gettimeofday:01 printf:01 printf:01 gettimeofday:01 26,:98 2007,:98 wrote:01 unix:01 unix:01 caml-list:01 latency:01 latter:03 latter:03 bugs:03 On Jun 26, 2007, at 3:35 PM, Sam Steingold wrote: >> Please, knows someone what I'm doing wrong? >> let t0 =3D Unix.gettimeofday () in >> Printf.printf "elapsed =3D %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 =20 clock but it is ultimately what the customers are seeing. If you don't =20 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 =20 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 =20 ~=3D 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 =20 program there is a huge difference between CPU and wall clock, then it is probably =20 a general load problem - But, you might see a huge difference only in certain part of the =20 program, in such cases, it should be investigated. If you only measure wall clock, or CPU Time, you might just miss some =20= part of the big picture. My 2 cents --=20 Best Regards, Qu=F4c