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