caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Nathaniel Gray" <n8gray@gmail.com>
To: "Edgar Friendly" <thelema314@gmail.com>
Cc: "Caml List" <caml-list@inria.fr>
Subject: Re: [Caml-list] Benchmarking different dispatch types
Date: Thu, 18 Jan 2007 14:33:00 -0800	[thread overview]
Message-ID: <aee06c9e0701181433u4c7d7009k60ef09292e41fe21@mail.gmail.com> (raw)
In-Reply-To: <45AED8C8.3080808@gmail.com>

On 1/17/07, Edgar Friendly <thelema314@gmail.com> wrote:
>
> well, running only 40,000 iterations is way too low because timing
> errors are going to get in the way of an accurate answer.

I forgot to mention that I also tried 400,000 and 4,000,000.  400K
produced similar results to 40K, while 4M produced some strange
results that didn't make sense.

> On my
> computer, I bumped the iterations up to max_int, and still the function
> call was still taking less than one CPU second of time (which I guess is
> the requirement for the warning to disappear).
>
> Here's my numbers from an Athlon XP-M 2000+ (1.53GHz), compiled with
> ocaml 3.09.3, cmd. line:
> $ ocamlfind ocamlopt -package "benchmark" -inline 0 unix.cmxa
> benchmark.cmxa  dispatch.ml
>
>
> Latencies for 1073741823 iterations of function, method, closure, obj.
> closure:
>   function:  0 WALL (-0.02 usr + -0.00 sys = -0.02 CPU)
>             (warning: too few iterations for a reliable count)
>     method: 15 WALL (11.34 usr +  0.49 sys = 11.83 CPU) @ 90764313.02/s
> (n=1073741823)
>    closure:  4 WALL ( 2.60 usr + -0.60 sys =  2.00 CPU) @ 536870911.50/s
> (n=1073741823)
> obj. closure:  8 WALL ( 4.31 usr +  0.03 sys =  4.34 CPU) @
> 247405950.00/s (n=1073741823)
>                        Rate     function       method obj. closure
> closure
>     function -5.36871e+10/s           --      -59250%      -21800%
> -10100%
>       method     90764313/s        -100%           --         -63%
>    -83%
> obj. closure    247405950/s        -100%         173%           --
>    -54%
>      closure    536870911/s        -101%         491%         117%
>      --
>
> Either function calls are just that stupidly efficient, or there's some
> optimization still going on. I'm guessing the second.

These results are clearly garbage, since the rate of function calls is
negative.  Or perhaps there's some time-travel going on...

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->


  parent reply	other threads:[~2007-01-18 22:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-18  1:12 Nathaniel Gray
2007-01-18  2:17 ` [Caml-list] " Edgar Friendly
2007-01-18  3:03   ` Jonathan Roewen
2007-01-18 23:57     ` Nathaniel Gray
2007-01-18 15:52   ` Remi Vanicat
2007-01-18 22:33   ` Nathaniel Gray [this message]
2007-01-19  0:03     ` Robert Roessler
2007-01-31 17:03   ` Christophe TROESTLER
2007-01-18 16:56 ` William D. Neumann
2007-01-19  0:50 ` Jacques Garrigue
2007-01-19  8:30   ` Nathaniel Gray

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=aee06c9e0701181433u4c7d7009k60ef09292e41fe21@mail.gmail.com \
    --to=n8gray@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=thelema314@gmail.com \
    /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).