Re: Plans for 2.8 - GNOME Managed Language Services?
- From: Miguel de Icaza <miguel ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: John Luke <jluke users sourceforge net>, Ryan McDougall <ryan mcdougall telusplanet net>, desktop-devel-list gnome org
- Subject: Re: Plans for 2.8 - GNOME Managed Language Services?
- Date: Sat, 27 Mar 2004 21:19:59 -0500
Hello,
> > As far as I am concerned (maybe I am biased), Java and the JVM offer no
> > advantages over mono. But mono has several including: language interop
> > (managed to unmanaged and also the reverse),
>
> Achievable in Java, see UNO, Jython, and so forth.
You can also write code written in any language on top of sendmail
macros, as it is turing complete. But being turing complete does not
mean that it is optimal for hosting a multitude of languages.
In particular the ECMA CLI is well suited for handling unsafe languages
lik C, C++ and Fortran as well as functional languages like lisp,
haskell, ml and the rest of that group.
This was achieved by bringing 14 languages during the development stages
from both commercial and academic groups to be ported to the MS VM, and
the feedback of these groups went directly into the VM.
As an example, the generics specification for the ECMA CLI v2 machine
had to change its semantics to allow the Eiffel folks to use this
feature on Eiffel instead of being forced to ignore it.
> > complete and mature open
> > source implementation based on two published standards
>
> The Mono implementation is a pretty new codebase. I don't think the JIT
> is super sophisticated, it isn't ported to all platforms, etc. Yes these
> things can be addressed, but they can also be addressed for a JVM.
Everything or nothing are super sophisticated. It only matters where
the bar is set.
Mono's current JIT engine has a number of optimizations:
peephole Peephole postpass
branch Branch optimizations
inline Inline method calls
cfold Constant folding
consprop Constant propagation
copyprop Copy propagation
deadce Dead code elimination
linears Linear scan global reg allocation
cmov Conditional moves
shared Emit per-domain code
sched Instruction scheduling
intrins Intrinsic method implementations
tailc Tail recursion and tail calls
loop Loop related optimizations
fcmov Fast x86 FP compares
leaf Leaf procedures optimizations
aot Usage of Ahead Of Time compiled code
precomp Precompile all methods before executing Main
Granted, not as complete as GCC, but with a nice built-in SSA
representation for example, we just implemented Arrays Bounds Check
Removal as part of the Mono "interview" process.
The ECMA CLI shines compared to Java because of two reasons:
* Value Types (structs or "byte blobs")
Java has nothing like this, and a lot of the memory pressure
that applications impose on the VM is caused by this.
* Platform Invoke
Platform Invoke is a lot faster than JNI. In the tests that
Novell did when choosing a platform for iFolder, P/Invoke was
faster (100 to 500 times faster, depending on the test).
* Generics are first-class citizens on the VM.
In Java, Generics are compiler sugar, in the ECMA CLI, they
are first class components of the VM, and hence classes will
be inlined for specific data types, without any "boxing".
On the performance side of things, in my opinion C# got something right
that Java did not: the default for methods is to not be virtual, while
the default in Java is to be virtual.
Miguel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]