caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "David Allsopp" <dra-news@metastack.com>
To: "'Andres Varon'" <avaron@gmail.com>
Cc: "'OCaml Mailing List'" <caml-list@inria.fr>
Subject: RE: [Caml-list] ocamlopt performance in 3.11
Date: Sat, 18 Oct 2008 18:36:09 +0200	[thread overview]
Message-ID: <30A4D55DA6F848278426563E47BE9A43@countertenor> (raw)
In-Reply-To: <273232B4-E482-4B0A-A4D1-B9B5876FDD60@gmail.com>

Andrew Varon wrote:
> On Oct 17, 2008, at 5:59 AM, David Allsopp wrote:
>
> > Pleased to say that I've got my 3 current projects compiled and  
> > running
> > under 3.11+beta1
> >
> > Unfortunately for one of the projects, its "reference" run (a
> > computationally intensive, repeatable operation the speed of which  
> > interests
> > me) has gone from repeatedly taking ~38 seconds in 3.10.2 to ~46  
> > seconds in
> > 3.11.0+beta1. The other two projects don't have as easy a way for me  
> > to
> > calibrate speed (they spend most of their time blocked on I/O  
> > anyway!).
> >
> > Has anything apart from the linker changed much in the 3.11 code  
> > generator
> > and has anyone else noticed a performance drop in any other programs?
>
> The Changes list do mention a number of important changes in the  
> runtime system.

Yes, still blushing that I'd failed to check the Changes file first...

> For most of my programs the bottleneck functions are implemented in C.  
> For one of the few cases where OCaml is taking care of the core loop,  
> ocaml 3.11.0beta1 produce a consistently slower native executable than  
> 3.10.2 by a very small factor (around 0.5%). I have not timed in  
> Windows, and I run Windows inside a virtual machine, so I'm not sure  
> if the differences I will observe there are just an artifact of that  
> setup.

OK, so I've tried using the -nodynlink option with all calls to ocamlopt and
spotted *no* timing difference. A quick binary comparison of the EXE
produced reveals that ocamlopt -nodynlink is making ABSOLUTELY NO difference
in the resulting code.

While I can see a benefit to having native code compile for use with dynlink
by default, given the performance hit I'm seeing, wouldn't it be better in
terms of backwards compatibility if you had to specify, say, -fordynlink in
order to compile a .cmx (and, presumably more importantly, .o file) for use
with ocamlopt -shared?


David


  reply	other threads:[~2008-10-20  8:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-17  9:59 David Allsopp
2008-10-17 12:32 ` [Caml-list] " Andres Varon
2008-10-18 16:36   ` David Allsopp [this message]
2008-10-20  8:15     ` Alain
2008-10-20 12:11       ` David Allsopp
2008-10-31 23:58       ` Jon Harrop

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=30A4D55DA6F848278426563E47BE9A43@countertenor \
    --to=dra-news@metastack.com \
    --cc=avaron@gmail.com \
    --cc=caml-list@inria.fr \
    /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).