[Mono-list] Re: C# -> Binary .. MCS to C++ cross compiler

Miguel de Icaza miguel@ximian.com
23 Oct 2002 01:26:02 -0400


> The problem with a CLI implementation on many platforms is simply speed.
> You can say what you want about the performance of IBM's JIT on x86, but for
> deployment on memory limited and performance limited embedded systems, a JIT
> simply isn't a good idea.

Well, it depends on the end of the spectrum you are at.  We could go as
far as saying that C for some systems is too much, or that even a stored
program is too much, and its better to just wire a state machine for a
particular problem.

Today you can purchase cell phones running Java and the Danger Hiptop
also uses it, and really, you can not complain about their speed. 

Probably a JIT customized for server performance is not a good idea, but
its open source: you can shrink it ;-)

> There is an especially large performance hit when you are talking about game
> platforms like the Playstation 2 or Gamecube, where the slower speed of the
> host processor and the lack of vectorization and other C and C++ compiler
> complex static optimization techniques really does make a big difference.

For those platforms you should probably run your time sensitive code in
a thread with finely tuned assembler/C/C++, and just keep some of your
logic in a higher, slower, non-time-sensitive portion of your code, so
it should not be an issue anyways. 

If you care too much about performance, you are better off using the
tools provided by the CPU vendor, and not a general purpose compiler
(ie, not Microsoft, not Borland's, not GCC's and not Ximian's).  

> Likewise, it is simply not practical to re-engineer all of the static
> optimization techniques for every possible target processor into the JIT
> system.  It will never be any more than a "good" solution for most embedded
> systems, and the fact that it is required to dynamically compile at load
> time is also another problem.

Thats what an ahead-of-time compiler would achieve (See NGen's code from
Zoltan for a proof of concept implementation).

In terms of speed, there is nothing stopping the engine of a JIT
compiler from being as good as a native compiler.  Typically JIT engines
have to make a trade off between code quality and compilation time, but
this issue becomes a moot point with an ahead-of-time compiler.

All of this, of course, within the scope of the .NET Framework, if you
do not want some of its features, then yes, you could live with a
simpler hack.