Re: Mono and GNOME. The long reply.

> > 	The CIL has one feature not found in Java though: it is
> >     byte code representation that is powerful enough to be used as a
> >     target for many languages: from C++, C, Fortran and Eiffel to Lisp
> >     and Haskell including things like Java, C#, JavaScript and Visual
> >     Basic in the mix.
> This statement is incorrect. Java is turing complete. There isnt a good
> compiler back end because nobody bothered to write one. In the gcc case
> its incredibly hard as gcc really isnt stack oriented.

Splitting things up:

	Java the language (not the point of discussion)

	The Java VM.

The Java VM is indeed turing complete, but does not provide the features
that simplify the development of a certain class of languages.  You can
still emulate it, but you will never get any kind of acceptable
performance out of generating emulated C++ in Java byte codes.

Both in the Java VM byte codes case and in the case of the CIL they both
impose a limit on the optimizations that front-end compilers can do. 
There is a point where further optimizations are wasteful because it is
not the role of the high level compiler to do these things (for example
loop unrolling will be done by the CIL->native compiler).

But useful things like constant folding can be kept there.  

I have posted some of my notes from my Columbia presentation on the
subject of optimization in CIL land here:

> This is already true. They use fortran because it has certain very specific
> language properties that make it faster for numeric operations than other
> languages. I doubt a .net bytecode system can extract that performance
> once you have lost the fortran properties. The .net system cannot properly
> represent the implicit vectorisation and parallelism properties of fortran
> so the bytecode procssors cannot re-extract them.

There are two cases here:

	* Writing new code.

	* Writing performance critical code.

Many scientists are interested in doing simulation that use existing
optimized code.  So for these simulations or quick runs, these days they
build python wrappers for Fortran.

These are provided out of the box for you with compilers like the Lahey
Fortran compiler:	

As for performing optimizations on CIL byte codes: the support did not
ship on 1.0, but it was part of Beta1 or Beta2, but they added support
for annotations that the JIT engine could take advantage of. 

They are indeed not in 1.0


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]