[Mono-devel-list] .NET Blog on performance.

[Miguel de Icaza]

Hello,

> I was wondering why we don't aot assemblies that we put in the GAC,
> and this seems like a good oppurtunity to ask.  I recently made a
> (hello-world level) test of just aot-ing mscorlib.dll and it was much
> slower than mono --optimize=all, which from the post above looks
> consistent with .NET.  I was under the impression that aot did the
> same operations as --optimize=all, is that right? I didn't try aot-ing
> more, perhaps someone has already done so and knows what sort of
> improvement it offers on mono.

The only reason is that AOT sometimes is good and sometimes is bad.

We are actively working on a solution.

It is good because the code is precompiled, so JIT time is reduced.  In
particular with applications like `mcs' if you AOT your compiler, corlib
and System assemblies MCS is roughly 33% faster than if you JIT.

So for MCS it would be a clear winner.  The problem is for having many
long-running Mono applications; AOT does not share the code, instead it
copies the code from the image into memory, so if you have 20 Mono
applications each one of those consumes all the memory requires as if
they JITed.

This itself is not terribly bad.

The other issue is that AOT code makes code slower, because the code
basically is "shared" so loads to static variables or static method
invocations have to be dereferenced and this might impact performance.

Our solution is two fold:

	* Define a new AOT file format that can be mmaped() read only,
	  with an ELF-like Procedure Linkage Table and Global Offset
	  Table (PLT and GOT) that are mapped read-write.

	  This means that all the JITed code would be shared across
	  multiple running Mono applications, reducing the memory
	  pressure on the system, and only small portions are specific
	  to each application.

	* Work on stronger optimizations.  Work is underway for new SSA-
	  based optimizations.  The most important one is SSAPRE that
	  has many side effects (Massi's blog has more information on
	  this).

	  SSAPRE JITed correctly its first method yesterday, so that
	  is very good news.

This is something you can expect in the Mono 1.2 timeframe.  After Mono
1.2 we will also rework the JIT engine to enable some early
optimizations that today are not possible (details will be posted as
part of the minutes of the Mono meetings this week in Boston).

Miguel.