[wg-camlp4] benchmarks

[Thomas Gazagnaire]

> For each file subdir/a.ml in src directory, there is a corresponding file subdir/a.ml in the cold directory, they have the same Parsetree, the only difference is that file in src should be preprocessed, while the file in cold is vanilla ocaml code that can be compiled without preprocessing.
> 
> So here 
> ocamlbuild src/FanDriver.native 
> and
> ocamlbuild cold/FanDriver.native
> does exactly the samething except for each file, when 
> compiling src/a.mo, it will compile as
> ocamlc.opt -c -pp fan src/a.ml 
> while when compiing cold/a.ml, it works as normal
> ocamlc.opt -c cold/a.ml

I still don't understand. Alain clearly showed my the overhead of ppx compared to bare-bone ocaml compilers using dynamic and static strategies. I understand where are the bottleneck and I'm confident that this will not be a concerned regarding compilation speed. Here I don't understand what you are measuring exactly . So what magic is hidden in your '-pp fan' ? Does it look for some predefined path to dynamically load macros, or is it a self-contained statically-linked compiler ? In the later case, how does it work in practice when people start assembling different pieces of syntax extensions (as it is already the case with camlp4) ?

 Honestly, I don't have a strong opinion on which final syntax/solution this group will pick up (ppx, fan or other with hopefully a light syntax proposal) , I just need concrete arguments to motivate me enough to dig into my old camlp4 code and port it to the new selected tool. Also, I think it's important to understand upfront the impact of this change on how we are building OCaml programs: should we change all of our compilation tools if we want decent compilation performance ? For instance, I think that the way people tend to use camlp4 and ocamlfind is very suboptimal in term of compilation speed, and I think this comes from a design issue in the first place. Let's not do that again please.

--
Thomas
 
> 
> For our non-trivial code base, our output shows that when compiling with preprocessing by Fan, its performance is 30s compared with 28s without preprocessing, this means with good engineering effort, even preprocessing as powerful as camlp4(Fan provide more features than camlp4) should bring not too much overhead, I did some experiment before, my feeling is that typechecking is the bottleneck in most cases.
> 
> The extra effort for Fan compared with compiling directly is a dumping process which dumps FanAst into Parsetree, since our output is already good enough in practice, I did not tune the GC for better performance.
> 
> >
> > Cheers,
> > Thomas
> >
> >>
> >>
> >> On Mon, Feb 11, 2013 at 7:20 AM, Gabriel Scherer <gabriel.scherer at gmail.com> wrote:
> >> On the other hand, build systems come and go (and ./configure is like
> >> the most horrible part to add logic to in most cases), while ocamlfind
> >> has proved a reliable tool as a basis for any OCaml ecosystem so far.
> >> If I can shelve some logic there without making the tool more complex
> >> or less elegant I think that would be better for everyone.
> >>
> >> On Mon, Feb 11, 2013 at 11:56 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
> >> > On 11 Feb 2013, at 10:45, Gabriel Scherer <gabriel.scherer at gmail.com> wrote:
> >> >
> >> >> On Mon, Feb 11, 2013 at 11:31 AM, Anil Madhavapeddy <anil at recoil.org> wrote:
> >> >>> It should work just fine with ppx, and has the advantage of reducing the number of ocamlfind calls per-file (which is a considerable overhead on large projects, since it has to scan the META directories on every invocation).
> >> >>
> >> >> That's of course rather orthogonal to the present discussion, but have
> >> >> you been in contact with Gerd to see if some caching solution would be
> >> >> possible? Intuitively it feels like ocamlfind could easily maintain a
> >> >> cache in /var/run/blah and only clean it on install/remove commands.
> >> >>
> >> >> (An external process invocation would still make some overhead so in
> >> >> you're case you'd still have to go all the way, but that could improve
> >> >> the threshold at which such ~hacks become interesting.)
> >> >
> >> > I don't think it's necessary to put this in ocamlfind, which does the job
> >> > it's designed to do very well. Just fix your build systems to run ocamlfind
> >> > at configure time, save the results, and apply them to the compiler flags
> >> > during the build phase.
> >> >
> >> > -anil
> >> >
> >> _______________________________________________
> >> wg-camlp4 mailing list
> >> wg-camlp4 at lists.ocaml.org
> >> http://lists.ocaml.org/listinfo/wg-camlp4
> >>
> >>
> >>
> >> --
> >> -- Regards, Hongbo
> >> _______________________________________________
> >> wg-camlp4 mailing list
> >> wg-camlp4 at lists.ocaml.org
> >> http://lists.ocaml.org/listinfo/wg-camlp4
> >
> 
> 
> 
> -- 
> -- Regards, Hongbo