[CakeML-dev] Let's remove max_app

Yong Kiam tanyongkiam at gmail.com
Tue Mar 7 23:20:27 UTC 2017


For max_app = 5 on clos_stubs (on the same commit). It does seem to affect
the compilation times a bit

--max_app=5 clos_stubs ---
btree

Compile to livesets
runtime: 2m57s,    gctime: 17.0s,     systime: 0.90000s.
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 314920463; Total: 314920463

514 oracles

Repeat compilation with oracle
runtime: 12m31s,    gctime: 1m00s,     systime: 5.7s.
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 1367010819; Total: 1367010819

fib
Compile to livesets
runtime: 2m49s,    gctime: 11.7s,     systime: 1.4s.
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 309732928; Total: 309732928

504 oracles

Repeat compilation with oracle
runtime: 10m36s,    gctime: 50.8s,     systime: 4.6s.
Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 1045845847; Total: 1045845847


On Tue, Mar 7, 2017 at 5:44 PM, Scott Owens <S.A.Owens at kent.ac.uk> wrote:

> Ok. I just fixed a bug in clos_to_bvl, but it shouldn’t affect compile
> times. Can we see some times with max_app at 4 or 5 to estimate how much
> the stubs are the problem.
>
> Scott
>
> > On 2017/03/07, at 22:36, Yong Kiam <tanyongkiam at gmail.com> wrote:
> >
> > The latest one on clos_stub: 4b566d5
> >
> > On Tue, Mar 7, 2017 at 5:17 PM, Scott Owens <S.A.Owens at kent.ac.uk>
> wrote:
> > Which commit is the clos_lang test with?
> >
> > Scott
> >
> > > On 2017/03/07, at 22:15, Yong Kiam <tanyongkiam at gmail.com> wrote:
> > >
> > > Here're the numbers with max_app = 10 on both branches for btree and
> fib:
> > >
> > > --- master ---
> > >
> > > btree
> > > Compile to livesets
> > > runtime: 6m39s,    gctime: 28.0s,     systime: 2.7s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 709909286; Total:
> 709909286
> > >
> > > 607 oracles
> > >
> > > Repeat compilation with oracle
> > > runtime: 29m39s,    gctime: 2m13s,     systime: 10.5s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 3239510671; Total:
> 3239510671
> > >
> > > fib
> > > Compile to livesets
> > > runtime: 6m36s,    gctime: 26.1s,     systime: 2.7s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 704732789; Total:
> 704732789
> > >
> > > 597 oracles
> > >
> > > Repeat compilation with oracle
> > > runtime: 25m19s,    gctime: 1m01s,     systime: 5.5s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 2618410506; Total:
> 2618410506
> > >
> > > --- clos_stubs ---
> > >
> > > btree
> > > Compile to livesets
> > > runtime: 4m01s,    gctime: 6.1s,     systime: 0.55600s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 446369571; Total:
> 446369571
> > >
> > > 551 oracles
> > >
> > > Repeat compilation with oracle
> > > runtime: 19m24s,    gctime: 1m52s,     systime: 9.7s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 2070001412; Total:
> 2070001412
> > >
> > > fib
> > > Compile to livesets
> > > runtime: 3m58s,    gctime: 6.3s,     systime: 0.64800s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 441178076; Total:
> 441178076
> > >
> > > 541 oracles
> > >
> > > Repeat compilation with oracle
> > > runtime: 16m29s,    gctime: 1m33s,     systime: 7.8s.
> > > Axioms: 0, Defs: 0, Disk: 0, Orcl: 0, Prims: 1588238417; Total:
> 1588238417
> > >
> > >
> > > On Tue, Mar 7, 2017 at 11:31 AM, Yong Kiam <tanyongkiam at gmail.com>
> wrote:
> > > I'll try and leave two of the benchmarks with max_app set to 10 before
> I go to lectures (still rebuilding on master).
> > >
> > > On Tue, Mar 7, 2017 at 11:24 AM, Magnus Myreen <
> magnus.myreen at gmail.com> wrote:
> > > 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/06832fd4/attachment.html>


More information about the Developers mailing list