Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
ocamlopt performance in 3.11
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-10-20 (08:03)
From: David Allsopp <dra-news@m...>
Subject: RE: [Caml-list] ocamlopt performance in 3.11
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?