<div dir="ltr"><div><div><div><div><div><div><div>Hello again,<br><br></div>I have done some more detailed experiments timing evaluation in the logic of different parts of the compiler (on a small section of the hello world program - basically an initial segment of the basis library).<br>The comparison is (roughly) between the [BOOT] custom parallelised-where-possible evaluation strategy originally used in the bootstrap evaluation, and the [EVAL] strategy of calling computeLib.CBV_CONV without any customisation (but using the compiler compset).<br>Here are the takeaway points:<br></div>- For compilation from source to labLang, the BOOT method is consistently faster by a small amount (10-30%)<br></div>- For compilation from labLang to target, EVAL is _much_ faster, like 8x.<br><br></div>So: we can split the evaluation and use BOOT for compilation down to labLang then EVAL for the rest, to get the best of both methods.<br><br></div>I am confused about how EVAL is getting so much speed in lab_to_target. Bear in mind that this is without parallelisation (afaik), which BOOT uses a lot in this phase of compilation. My current guess is that there must be some very smart custom conversions installed for lab_to_target that don't fire under BOOT's strategy. For example, did anyone write custom conversions for calculating sec_ok for previously encoded instructions? Calculating sec_ok under BOOT's strategy, even in parallel, often takes longer than EVAL on the entire lab_to_target evaluation. I know there are custom conversions for memoising the encoder (which both strategies benefit from), but are those custom conversions doing more than I'm aware of?<br><br></div>Cheers,<br></div>Ramana<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 May 2017 at 23:52, Magnus Myreen <span dir="ltr"><<a href="mailto:magnus.myreen@gmail.com" target="_blank">magnus.myreen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If I remember correctly, the standard kernel has special combined<br>
primitives and other tricky for fast EVAL. Maybe your conversions<br>
weren't using the right things in the kernel. -- Magnus<br>
<div><div class="h5"><br>
On 1 May 2017 at 15:16, Ramana Kumar <<a href="mailto:Ramana.Kumar@cl.cam.ac.uk">Ramana.Kumar@cl.cam.ac.uk</a>> wrote:<br>
> Hi all,<br>
><br>
> On the cleanup branch I've been making the compilation-in-logic method used<br>
> by the bootstrap into a library to be used for compiling in the logic<br>
> generally. (This is issue #249.) The bootstrap method involves lots of<br>
> custom conversions and parallelised evaluation where possible. Preliminary<br>
> use of it to compile the characteristic examples suggests, however, that it<br>
> might be a lot slower than what was used before (essentially EVAL using the<br>
> compiler compset).<br>
><br>
> While we might expect some slowdown due to additional printing and<br>
> intermediate definitions, I would have overall expected a speedup. I'm just<br>
> noticing this based on my recollection of building the examples the EVAL way<br>
> (15 mins I thought) and so may be totally wrong about the slowdown. More<br>
> careful experiments would need to be done. And if EVAL really is faster, I'd<br>
> want to understand why! Or how to exploit it further!<br>
><br>
> Systematic experiments on various strategies for evaluation in the logic<br>
> could be interesting. We have a big program (the compiler) to do them with.<br>
> I tried various strategies for one compilation phase once (it's still in the<br>
> comments of x64BootstrapScript.sml) and could never beat EVAL and never<br>
> understood why not, because I was doing the most direct efficient custom<br>
> conversion I thought possible.<br>
><br>
> On a separate note, I will be out of contact (and not working on CakeML -<br>
> I'll be at an intensive training camp) from Wednesday for a week. I hope<br>
> nothing urgent comes up, and if you want to plan for any contingencies<br>
> beforehand, email me. (I will probably still have email during the week, but<br>
> not much access.)<br>
><br>
> Cheers,<br>
> Ramana<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Developers mailing list<br>
> <a href="mailto:Developers@cakeml.org">Developers@cakeml.org</a><br>
> <a href="https://lists.cakeml.org/listinfo/developers" rel="noreferrer" target="_blank">https://lists.cakeml.org/<wbr>listinfo/developers</a><br>
><br>
</blockquote></div><br></div>