[CakeML-dev] Let's remove max_app

[Scott Owens]

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