From: "Jonathan Roewen" <jonathan.roewen@gmail.com>
To: "Edgar Friendly" <thelema314@gmail.com>
Cc: "Nathaniel Gray" <n8gray@gmail.com>, "Caml List" <caml-list@inria.fr>
Subject: Re: [Caml-list] Benchmarking different dispatch types
Date: Thu, 18 Jan 2007 16:03:14 +1300 [thread overview]
Message-ID: <ad8cfe7e0701171903n70d05fb4ka68b2de6248c4713@mail.gmail.com> (raw)
In-Reply-To: <45AED8C8.3080808@gmail.com>
>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
>
next prev parent reply other threads:[~2007-01-18 3:03 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 [this message]
2007-01-18 23:57 ` Nathaniel Gray
2007-01-18 15:52 ` Remi Vanicat
2007-01-18 22:33 ` Nathaniel Gray
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=ad8cfe7e0701171903n70d05fb4ka68b2de6248c4713@mail.gmail.com \
--to=jonathan.roewen@gmail.com \
--cc=caml-list@inria.fr \
--cc=n8gray@gmail.com \
--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).