Re: [Caml-list] Benchmarking different dispatch types

[Edgar Friendly <thelema314@gmail.com>]

Nathaniel Gray wrote:
> 
> Here's the output (on a PPC G4 1.25 GHz):
> 
> ========
> Latencies for 40000 iterations of function, method, closure, obj. closure:
>  function:  0 WALL ( 0.00 usr + -0.00 sys =  0.00 CPU) @
> 305343511.45/s (n=40000)
>            (warning: too few iterations for a reliable count)
>    method:  0 WALL ( 0.00 usr + -0.00 sys =  0.00 CPU) @
> 27081922.82/s (n=40000)
>            (warning: too few iterations for a reliable count)
>   closure:  0 WALL ( 0.00 usr +  0.00 sys =  0.00 CPU) @
> 30280090.84/s (n=40000)
>            (warning: too few iterations for a reliable count)
> obj. closure:  0 WALL ( 0.00 usr +  0.00 sys =  0.00 CPU) @
> 26058631.92/s (n=40000)
>            (warning: too few iterations for a reliable count)
>                    Rate       method obj. closure      closure     function
>      method  25974026/s           --          -5%         -16%         -90%
> obj. closure  27210884/s           5%           --         -12%        
> -89%
>     closure  31007752/s          19%          14%           --         -88%
>    function 254777070/s         881%         836%         722%           --
> 
> Interesting, but are they meaningful?  The warnings from Benchmark are
> troubling, but I didn't have any immediate ideas on how to get rid of
> them.  Any suggestions?
> 
> Thanks,
> -n8
> 
> [1] http://ocaml-benchmark.sourceforge.net
> 

well, running only 40,000 iterations is way too low because timing
errors are going to get in the way of an accurate answer.  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.

E.