<br><br><div class="gmail_quote">On Tue, Feb 12, 2013 at 9:02 AM, Thomas Gazagnaire <span dir="ltr"><<a href="mailto:thomas@ocamlpro.com" target="_blank">thomas@ocamlpro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
</div>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) ?<br>
</blockquote><div>It's a statically-linked compiler. I am concerned about performance as much as you, since I have to bootstrap Fan itself everytime I add new features. </div><div>Unlike Camlp4, Fan's design encourages static linking or dynamic linking as much as you can. When you have different pieces of extensions, the static linking or dynamic linking <b>only registe</b>r what features it provides, here the order does not matter, and it does not have any side effect otherwise, the file in src/<a href="http://a.ml">a.ml</a> specifies which syntax extension it wants to pick</div>
<div>for example in src/<a href="http://a.ml">a.ml</a></div><div>---------------------------------</div><div>#load_syntax ["normal"];;</div><div>#filter ["serialize"];;</div><div>blabla ...</div><div>---------------------------------</div>
<div>itself states what syntax or ast rewriter it needs, so here you only need to supply '-pp fan', it could figure out how to parse and transform the Ast by itself as long as those features needed are registered.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 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.<br>

<br>
--<br>
Thomas<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> 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.<br>

><br>
> 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.<br>

><br>
> ><br>
> > Cheers,<br>
> > Thomas<br>
> ><br>
> >><br>
> >><br>
> >> On Mon, Feb 11, 2013 at 7:20 AM, Gabriel Scherer <<a href="mailto:gabriel.scherer@gmail.com">gabriel.scherer@gmail.com</a>> wrote:<br>
> >> On the other hand, build systems come and go (and ./configure is like<br>
> >> the most horrible part to add logic to in most cases), while ocamlfind<br>
> >> has proved a reliable tool as a basis for any OCaml ecosystem so far.<br>
> >> If I can shelve some logic there without making the tool more complex<br>
> >> or less elegant I think that would be better for everyone.<br>
> >><br>
> >> On Mon, Feb 11, 2013 at 11:56 AM, Anil Madhavapeddy <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br>
> >> > On 11 Feb 2013, at 10:45, Gabriel Scherer <<a href="mailto:gabriel.scherer@gmail.com">gabriel.scherer@gmail.com</a>> wrote:<br>
> >> ><br>
> >> >> On Mon, Feb 11, 2013 at 11:31 AM, Anil Madhavapeddy <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br>
> >> >>> 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).<br>

> >> >><br>
> >> >> That's of course rather orthogonal to the present discussion, but have<br>
> >> >> you been in contact with Gerd to see if some caching solution would be<br>
> >> >> possible? Intuitively it feels like ocamlfind could easily maintain a<br>
> >> >> cache in /var/run/blah and only clean it on install/remove commands.<br>
> >> >><br>
> >> >> (An external process invocation would still make some overhead so in<br>
> >> >> you're case you'd still have to go all the way, but that could improve<br>
> >> >> the threshold at which such ~hacks become interesting.)<br>
> >> ><br>
> >> > I don't think it's necessary to put this in ocamlfind, which does the job<br>
> >> > it's designed to do very well. Just fix your build systems to run ocamlfind<br>
> >> > at configure time, save the results, and apply them to the compiler flags<br>
> >> > during the build phase.<br>
> >> ><br>
> >> > -anil<br>
> >> ><br>
> >> _______________________________________________<br>
> >> wg-camlp4 mailing list<br>
> >> <a href="mailto:wg-camlp4@lists.ocaml.org">wg-camlp4@lists.ocaml.org</a><br>
> >> <a href="http://lists.ocaml.org/listinfo/wg-camlp4" target="_blank">http://lists.ocaml.org/listinfo/wg-camlp4</a><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> -- Regards, Hongbo<br>
> >> _______________________________________________<br>
> >> wg-camlp4 mailing list<br>
> >> <a href="mailto:wg-camlp4@lists.ocaml.org">wg-camlp4@lists.ocaml.org</a><br>
> >> <a href="http://lists.ocaml.org/listinfo/wg-camlp4" target="_blank">http://lists.ocaml.org/listinfo/wg-camlp4</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> -- Regards, Hongbo<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Regards, Hongbo