Re: Putting the 'Mono debate' back on the rails
- From: Ben Maurer <bmaurer andrew cmu edu>
- To: "Jason D. Clinton" <me jasonclinton com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Putting the 'Mono debate' back on the rails
- Date: Fri, 21 Jul 2006 14:20:58 -0400 (EDT)
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:
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.
] [Thread Prev