[MLton-devel] Re: MLton and profiling

[Andreas Rossberg]

Stephen Weeks wrote:
> 
> Yes, that was a change that went in between 20030130 and 20030209.  I
> figured it was better to keep track of copies of a function that the
> implementation creates.  There's nothing specific to currying.  It's
> really just dependent on whatever
> monomorphisation/polyvariance/inlining happens.  In any case, the user
> guide now has the following paragraph.
> 
>   {\mlton}'s optimizer may duplicate source functions for any of a
>   number of reasons.  By default, each of these duplicates is treated
>   as a different function for the purposes of profiling.  It you would
>   like all of the copies of a function to be treated as one, you can
>   compile the program with {\tt -profile-combine true}.  Even with
>   this, copies of a function that arise from functor duplication are
>   still kept separate.

OK, I see. That's reasonable (although I probably would prefer the 
inverse default).

Still, I am surprised to see 20 copies of Type.clone. I cannot imagine 
how there can be that many monomorphic instances, nor would I expect it 
to be inlined. Can you make a quick, informed guess?


>>BTW, I would love to apply profiling to parts of the Alice system (which 
>>really needs it...). Unfortunately, it makes heavy use of extensions 
>>like or patterns and vector expressions. Is there any chance that MLton 
>>will support them in the future?
> 
> It's very unlikely.  I have a pretty strong opinion that lack of
> portability (caused by not compilers not following the standard) is a
> serious problem with SML.  I'd much rather encourage you to make Alice
> standard.  Perhaps the profiler will be just the right push :-).

I understand your sentiment. On the other hand, no programming language 
yet survived more than 10 years without evolution. And experimental 
extensions are necessary to let new features grow in practice. I have to 
admit that Alice has a shameless lot of them... see 
http://www.ps.uni-sb.de/alice/manual/language.html if you want to 
experience the full horror :-).

Would you also oppose a collaborative attempt of all SML implementers to 
find a procedure for agreeing on certain extensions (that proved useful 
and mature enough) being promoted to the status of "quasi-standard"? To 
me, this seems to be a reasonable migration path to some SML+, whatever 
that will be called.

   - Andreas



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel