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
============================