[CakeML-dev] Let's remove max_app
Scott Owens
S.A.Owens at kent.ac.uk
Tue Mar 7 15:04:26 UTC 2017
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
More information about the Developers
mailing list