<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Okay then. Obviously proceed with caution, as always.<div class=""><br class=""></div><div class="">MetiTarski also has high standards, and doesn’t have the added security of a kernel architecture. Every significant change is checked by regression testing using tools that highlight significant changes in the runtime of the full test suite. This test suite includes many statements known to be false in order to catch soundness errors. Not that I was expecting any in this case: the required changes were small and logically trivial (mainly, converting between large and small integers).</div><div class=""><br class=""></div><div class="">I think it would be quite straightforward to try the experiment of building Isabelle with the new compiler, but I would need some help with our present setup (whereas I recall we keep our own copy of the compiler packaged in a special way somewhere). Also now is perhaps about time to accumulate changes, though I don’t expect to see many.</div><div class=""><br class=""></div><div class="">Can we wait until the next release is out? And yes, I could do it myself.</div><div class=""><br class=""></div><div class="">Is the question of 32 versus 64 bits relevant here? I suspect it isn’t. Any integers of ours requiring more than 32 bits need to be large integers.</div><div class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div class="">Larry</div></span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 2 Nov 2016, at 15:29, Makarius <<a href="mailto:makarius@sketis.net" class="">makarius@sketis.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 02/11/16 15:58, Lawrence Paulson wrote:<br class=""><blockquote type="cite" class="">I have to say, I’m absolutely mystified by the response to my suggestion.<br class=""></blockquote><br class="">Why? I did not reject the idea, but only put it into the context of<br class="">Isabelle. MetiTarski is a small research experiment, but Isabelle a huge<br class="">and complex software product, with very high standards.<br class=""><br class=""><br class=""><blockquote type="cite" class="">We have spent a lot of time discussing problems caused by the cost of<br class="">regression testing, and now we have the possibility of reducing that by 30%.<br class=""></blockquote><br class="">Where is the empirical measurement for Isabelle? Without that it is just<br class="">speculation.<br class=""><br class="">A quick test with x86_64 and int = FixedInt might actually give some<br class="">ideas about the order of potential performance improvement. Do you want<br class="">to make one?<br class=""><br class=""><br class="">In the Jenkins project, there were also proposals to move to 64bit by<br class="">default, and thus lose a lot of performance. (The general waste of<br class="">resources of Jenkins is caused by high-level policies, though, and<br class="">theses were not openly discussed so far.)<br class=""><br class=""><br class=""><blockquote type="cite" class="">As to changes in behaviour that could be caused by overflows, I checked:<br class="">exception Overflow is explicitly caught in only two places throughout<br class="">the sources, both in HOL decision procedures (and therefore well outside<br class="">the kernel) while the wildcard exception is caught in three places in<br class="">Pure.<br class=""></blockquote><br class="">I routinely check these things before each release. Catch-all patterns<br class="">are more frequent than that, but they are OK.<br class=""><br class="">I don't think that such a change would cause wrong results, but just<br class="">unexpected failure, and that is already bad enough in everyday use.<br class=""><br class=""><br class=""><blockquote type="cite" class="">No exception handlers had to be added when I converted MetiTarski<br class="">to use fixed integers. An uncaught exception doesn’t prove anything, of<br class="">course.<br class=""></blockquote><br class="">BTW, you have a lot of catch-all exception handlers in MetiTarski. The<br class="">Isabelle/ML IDE shows that -- my changeset from last summer is attached<br class="">again.<br class=""><br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Makarius<br class=""><br class=""><span id="cid:D5A7F24B-5519-4378-9F46-DDD91DCCF313@cl.cam.ac.uk"><ch-PIDE.txt></span></div></div></blockquote></div><br class=""></div></body></html>