MLton information

Suresh Jagannathan suresh@research.nj.nec.com
Thu, 1 Apr 1999 11:16:28 -0500


   From: "Frank A. Christoph" <christo@nextsolution.co.jp>
   Date: Thu, 1 Apr 1999 10:50:21 +0900
   MIME-Version: 1.0
   Content-Type: text/plain;
	   charset="iso-2022-jp"
   Content-Transfer-Encoding: 7bit
   X-Priority: 3 (Normal)
   X-MSMail-Priority: Normal
   X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
   X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
   Importance: Normal

   I have looked at the performance page, and I was wondering why the kit
   example (this is the MLKit, right?) did so poorly. From what I know of
   MLKit, it is especially designed to be modular, and I would have thought
   that it could benefit from a whole-program analysis.

   BTW, are there any technical papers available on the MLton implementation?

   --FC

Yes, you're right, it was surprising to us as well.  One conjecture is that the
implementation of the KIT was optimized to work well with NJ.  Another is based
on the observation that C-function sizes for the kit are quite large, which may
reduce the quality of the assembler output produced by C.  Interestingly enough,
in looking at the number of dispatches and coercions inserted by the closure
convertor, we find the kit having far fewer (as percentage of total number of
calls) than the self-compile.  We're still investigating the discrepancy.

We've submitted a paper to ICFP this year; the postscript of the submission
follows.

Regards,

			-- Suresh

============================