[MLton-devel] Re: MLton and profiling

[Stephen Weeks]

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

I believe it is being inlined.  But this may not mean what you think
-- it does not mean the entire body of Type.clone is being duplicated.
Inlining in MLton happens after closure conversion on an IL with no
nested functions.  So, inlining of Type.clone does not copy its local
helper functions, clone and clone', which are separate.  Once you
remove these helper functions, Type.clone is actually very small -- it
consructs two ref cells and a closure for its helpers.  Thus it is
very natural that Type.clone is always inlined.

The helper clone is also pretty small, and appears to be inlined
everywhere as well.  The helper clone' is larger, and is not inlined.

If you run mlprof -show-line true, you can see which clones are being
copied.

> >>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 :-).

Just to be clear, I did not mean to propose to make the language that
Alice implements follow the standard.  I think playing with new
features is great.  I was proposing that you make the language that
implements Alice be standard.  That way you can use compilers other
than SML/NJ to compile (and profile :-) your implementation.

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

I think it would be great for this to happen.  As I said some time ago
on sml-implementors, I would really like to see standardization of an
FFI and CM/PM/whatever system.  I personally don't know of any
language features (subtyping, higher-order modules, ...) where the
the benefit of adding them outweighs the cost.  But I am not opposed
in principle as long as all implementations agree.

A large part of my objection to the extensions in SML/NJ is not so
much because they are extensions, but because there is no clear
delineation between what is standard and what is not.  Consequently,
many users think they are writing standard code when in fact they are
not.  You are far from the first to tell us that you would like to use
your program with MLton, but cannot due to use of SML/NJ extensions,
either accidentally or by choice.  Some users find it very frustrating
to find out they have unknowingly written unportable code.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel