ocamlopt performance in 3.11

ocamlopt performance in 3.11

[David Allsopp]

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?


David

(Machine setup: Windows XP SP3 + MinGW/gcc 3.4.4 running on an Intel Core
Duo T7200 @ 2GHz with 2GB RAM)

Re: [Caml-list] ocamlopt performance in 3.11

[Andres Varon]

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.

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.

Andres

My setup:

     System Software Overview:

       System Version: Mac OS X 10.5.5 (9F33)
       Kernel Version: Darwin 9.5.0
       XCode: 3.1.1

     Hardware Overview:

       Model Name: Mac Pro
       Model Identifier: MacPro2,1
       Processor Name: Quad-Core Intel Xeon
       Processor Speed: 3 GHz
       Number Of Processors: 2
       Total Number Of Cores: 8
       L2 Cache (per processor): 8 MB
       Memory: 16 GB
       Bus Speed: 1.33 GHz



>
>
>
> David
>
> (Machine setup: Windows XP SP3 + MinGW/gcc 3.4.4 running on an Intel  
> Core
> Duo T7200 @ 2GHz with 2GB RAM)
>
> _______________________________________________
> 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

RE: [Caml-list] ocamlopt performance in 3.11

[David Allsopp]

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

Re: [Caml-list] ocamlopt performance in 3.11

[Alain]

David Allsopp wrote:
> 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.

-nodynlink only makes a difference for the AMD64 backend. It is accepted 
by ocamlopt for all ports in order to simplify Makefiles.

> 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?

There were reasonable arguments for turning the "ready for dynlink" 
behavior on by default, namely that nobody would do it otherwise in the 
Makefiles of their distributed libraries since it is required only on 
one port. Also, according to a few benchmarks, the impact on performance 
is very limited.


-- Alain

RE: [Caml-list] ocamlopt performance in 3.11

[David Allsopp]

Alain Frisch wrote:
> David Allsopp wrote:
> > 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.
>
> -nodynlink only makes a difference for the AMD64 backend. It is accepted 
> by ocamlopt for all ports in order to simplify Makefiles.

Ah, I didn't realise that. Perhaps ocamlopt -help could include a note to
that effect?

> > 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?
>
> There were reasonable arguments for turning the "ready for dynlink" 
> behavior on by default, namely that nobody would do it otherwise in the 
> Makefiles of their distributed libraries since it is required only on 
> one port.

Indeed - that's the benefit I was referring to! However...

> Also, according to a few benchmarks, the impact on performance is very
> limited.

Then why might my program be running ~25% slower when compiled with ocamlopt
3.11.0 vs 3.10.2? I'm assuming that there's little to no difference between
ocamlopt using masm and ocamlopt using gas in terms of resulting
performance?


David

Re: [Caml-list] ocamlopt performance in 3.11

[Jon Harrop]

On Monday 20 October 2008 09:15:28 Alain wrote:
> David Allsopp wrote:
> > 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.
>
> -nodynlink only makes a difference for the AMD64 backend. It is accepted
> by ocamlopt for all ports in order to simplify Makefiles.

Would be good if all command line options to the compilers (e.g. -ffast-math) 
were accepted by ocamlopt on all ports for the same reason.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e