Re: Putting the 'Mono debate' back on the rails

[Ben Maurer <bmaurer andrew cmu edu>]

On Fri, 21 Jul 2006, Jason D. Clinton wrote:

> On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote:
> > I don't think this is an item worth dividing on. For languages like Mono
> > (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is
> > purely a case-by-case performance decision.
> ...
> > The statement that performance is generally higher isn't quite correct.
> > However, it's completely besides the point for this discussion.
> ...
> > Again, completely besides the point. The decision to AOT would be based on
> > measurements. It doesn't address any of the issues in Jeff's email.
>
> Well I respectfully disagree and I find your statements that my
> statements don't address any issues raised by Jeff very puzzling as they
> were specifically influenced by the framing Jeff did in the issue
> directly above the two I quoted. Quoth Jeff:
>
> > * Should Gtk#/Mono applications be accepted into the Desktop suite?
> ...
> >   - performance (memory and cpu) is a red herring here; we all *know* that
> ...
> >   - can we resolve the dissonance between delivering a coherent Desktop (a
> >     goal of the Desktop suite) and suggesting that vendors deliver multiple
> >     vm/language/binding/runtime platforms to satisfy it, and demand that
> >     users stomach it too? (this has also been raised as a performance issue)
>
> You are, of course, welcome to disagree with my suggestion. I have no
> idea if it's a good one or not but I thought it was worth bringing up.
>
> I think that "inventivizing" projects to push toward an AOT approach
> could be one way to help allay the people pounding their fists over the
> perceived performance of the desktop OOTB.

AOT is *not* always faster. There are lots of variables. For example, at 
JIT time, the compiler can make some assumptions that AOT can not (for 
example, if you have a static readonly field [static final in java], JITs 
can inline the constant value because it will never change. AOT can't do 
this because the value is computed in the static constructor).

In some cases, AOT can incresae startup time becasue the assembly used by 
CPUs is generally larger than the IL in a JIT. In these cases, it can be 
*faster* to compile than it is to read more from the disk see:

http://blogs.msdn.com/ricom/archive/2004/10/18/244242.aspx

for a bit about this.

We should encourage performance. However, making divisions based on 
specific optimization techniques is the wrong direction. Also, getting off 
track and talking about specific optimization techniques while making high 
level decisions isn't going to help.

If you want to talk more about AOT in Mono (or other runtimes), this is 
simply not the list to do it.

-- Ben