>From what I understand, anything other than a function is bound to be
fairly slow in comparison.

For closures, you first have to build the closure from the
environment, and then invoke it; and methods require some sort of
lookup. Functions, on the other hand, are fairly simply: it's just a
call to a known address (putting aside passing the actual arguments to
the function/method call).

Sure, there may be some optimisations to be gained in some places, or
a bit over-simplistic in other cases, but the basic premise is the
same for supporting the overall view the numbers give (not so much the
ratios) IMO.

Jonathan

On 1/18/07, Edgar Friendly <thelema314@gmail.com> wrote:
> 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.
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>