[CakeML-dev] Let's remove max_app
Magnus Myreen
magnus.myreen at gmail.com
Tue Mar 7 16:24:24 UTC 2017
What are we measuring? I'm keen to know how high max_app can be. I suspect
we need it to be 10 in order to avoid generating bad applications when
compiling the compiler. -- Magnus
On Tue, 7 Mar 2017 at 16:28, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
> Hold off for now, I just thought of another easy improvement.
>
> Scott
>
> > On 2017/03/07, at 15:12, Yong Kiam <tanyongkiam at gmail.com> wrote:
> >
> > I can get you a before/after test on master and clos_stub on one of the
> benchmarks compiled in the logic.
> >
> > (will take awhile though)
> >
> > On Tue, Mar 7, 2017 at 10:04 AM, Scott Owens <S.A.Owens at kent.ac.uk>
> wrote:
> > I should clarify that this is on the clos_stub branch, which I haven’t
> merged back to master.
> >
> > Scott
> >
> > > On 2017/03/07, at 15:00, Scott Owens <S.A.Owens at kent.ac.uk> wrote:
> > >
> > > I’ve just finished the first improvement on reducing the number of
> stubs. I’d like to see where we are before trying to get further
> improvements. Can you re-try this, or even better, tell me what you were
> doing to get these numbers. Can we get anything meaningful without running
> the bootstrap (and the attendant 2 day wait)?
> > >
> > > Scott
> > >
> > >> On 2017/03/05, at 08:21, Magnus Myreen <magnus.myreen at gmail.com>
> wrote:
> > >>
> > >> Hi all,
> > >>
> > >> We should get rid of max_app. Reasons:
> > >>
> > >> 2. The current compilation strategy produces too much stub code in
> > >> clos_to_bvl. If we really must have max_app (I argue below that
> > >> we don't), then it should be something like 10 or 15. With the
> > >> current compilation strategy, the binary produced for max_app=9 is
> > >> 176 kb larger than the binary for max_app=3. I wanted to try
> > >> compiling with max_app=10, but that was taking more than 5
> > >> minutes. Compiling with max_app=3 takes 7 seconds for me. I
> > >> believe the slow down in compilation speed with differing max_app
> > >> values is caused by the rapid increase in code size (number of
> > >> stubs in clos_to_bvl) as max_app gets larger. My measurements
> > >> are below while compiling factorial (and the basis library):
> > >>
> > >> max_app=1: 10.810s (* very little room for opts in basis *)
> > >> max_app=2: 8.724s
> > >> max_app=3: 7.872s (* allows optimisations in basis code *)
> > >> max_app=4: 8.935s
> > >> max_app=5: 11.608s
> > >> max_app=6: 21.771s
> > >> max_app=7: 42.932s
> > >> max_app=8: 1m24.872s
> > >> max_app=9: 3m9.745s
> > >
> > > _______________________________________________
> > > Developers mailing list
> > > Developers at cakeml.org
> > > https://lists.cakeml.org/listinfo/developers
> >
> > _______________________________________________
> > Developers mailing list
> > Developers at cakeml.org
> > https://lists.cakeml.org/listinfo/developers
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cakeml.org/pipermail/developers/attachments/20170307/1da65fe9/attachment-0001.html>
More information about the Developers
mailing list