Version française
Home     About     Download     Resources     Contact us    
Browse thread
Benchmarking different dispatch types
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Nathaniel Gray <n8gray@g...>
Subject: Re: [Caml-list] Benchmarking different dispatch types
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 -->