[Mono-devel-list] .NET Blog on performance.
Miguel de Icaza
miguel at novell.com
Sat Oct 23 13:53:16 EDT 2004
> 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
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
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).
More information about the Mono-devel-list