* ocamlopt performance in 3.11 @ 2008-10-17 9:59 David Allsopp 2008-10-17 12:32 ` [Caml-list] " Andres Varon 0 siblings, 1 reply; 6+ messages in thread From: David Allsopp @ 2008-10-17 9:59 UTC (permalink / raw) To: 'OCaml Mailing List' 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] ocamlopt performance in 3.11 2008-10-17 9:59 ocamlopt performance in 3.11 David Allsopp @ 2008-10-17 12:32 ` Andres Varon 2008-10-18 16:36 ` David Allsopp 0 siblings, 1 reply; 6+ messages in thread From: Andres Varon @ 2008-10-17 12:32 UTC (permalink / raw) To: David Allsopp; +Cc: 'OCaml Mailing List' 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [Caml-list] ocamlopt performance in 3.11 2008-10-17 12:32 ` [Caml-list] " Andres Varon @ 2008-10-18 16:36 ` David Allsopp 2008-10-20 8:15 ` Alain 0 siblings, 1 reply; 6+ messages in thread From: David Allsopp @ 2008-10-18 16:36 UTC (permalink / raw) To: 'Andres Varon'; +Cc: 'OCaml Mailing List' 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] ocamlopt performance in 3.11 2008-10-18 16:36 ` David Allsopp @ 2008-10-20 8:15 ` Alain 2008-10-20 12:11 ` David Allsopp 2008-10-31 23:58 ` Jon Harrop 0 siblings, 2 replies; 6+ messages in thread From: Alain @ 2008-10-20 8:15 UTC (permalink / raw) To: David Allsopp; +Cc: 'Andres Varon', 'OCaml Mailing List' 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [Caml-list] ocamlopt performance in 3.11 2008-10-20 8:15 ` Alain @ 2008-10-20 12:11 ` David Allsopp 2008-10-31 23:58 ` Jon Harrop 1 sibling, 0 replies; 6+ messages in thread From: David Allsopp @ 2008-10-20 12:11 UTC (permalink / raw) To: 'Alain'; +Cc: 'Andres Varon', 'OCaml Mailing List' 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] ocamlopt performance in 3.11 2008-10-20 8:15 ` Alain 2008-10-20 12:11 ` David Allsopp @ 2008-10-31 23:58 ` Jon Harrop 1 sibling, 0 replies; 6+ messages in thread From: Jon Harrop @ 2008-10-31 23:58 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-10-31 22:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-17 9:59 ocamlopt performance in 3.11 David Allsopp 2008-10-17 12:32 ` [Caml-list] " Andres Varon 2008-10-18 16:36 ` David Allsopp 2008-10-20 8:15 ` Alain 2008-10-20 12:11 ` David Allsopp 2008-10-31 23:58 ` Jon Harrop
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).