[wg-camlp4] benchmarks

[Hongbo Zhang]

On Tue, Feb 12, 2013 at 9:02 AM, Thomas Gazagnaire <thomas at ocamlpro.com>wrote:

>
>
> 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) ?
>
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.
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 *only registe*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.ml specifies which syntax extension it wants to pick
for example in src/a.ml
---------------------------------
#load_syntax ["normal"];;
#filter ["serialize"];;
blabla ...
---------------------------------
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.



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


-- 
-- Regards, Hongbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130212/6ec7fea0/attachment.html>