[Mono-list] Re: The Mauve unicode testcase and VM performance
Tue, 13 Apr 2004 14:55:03 -0400
Mark Wielaard wrote:
> You then still need the original "exe" for execution.
> The man page says about --aot:
> This option is used to precompile the CIL code in the specified
> assembly to native code. The generated code is stored in a file
> with the extension .so. This file will be automatically picked
> up by the runtime when the assembly is executed.
> This pre-compiles the methods, but the original assembly is
> still required to execute as this one contains the metadata and
> exception information which is not availble on the generated
> file. When precompiling code, you might want to compile with
> all optimizations (-O=all). Pre-compiled code is position inde-
> pendent code.
> load test overhead total
> Old: 1703 1292 3174 6169
> New: 2944 1337 624 4905
> Oat: 2944 1312 626 4882
> So that doesn't seem to help in this case (or I did something wrong and
> it isn't picking up the mauve.exe.so after all).
Did you try --aot'ing classpath.dll, IK.VM.NET.dll etc?
I'd imagine that this particular microbenchmark spends a large
proportion of its time inside classpath itself, suggesting that merely
JITing the mauve part wouldn't help much.
The man page you cited says that --aot "precompiles the CIL code in the
specified assembly". In .NET terminology, each dll or exe is a separate
assembly. So I take that doc to imply that you need to separately AOT
each dll as well as the exe itself.
Interestingly, my installation of mono (from debian sid) doesn't even
come with its own libraries AOT'd. I'd have thought that you'd get the
best performance by AOT'ing *all* the libraries, including (and
especially) the low-level platform ones such as System.dll and
CC'ing mono-list for any insight they might have into why (or why not)
you might want to AOT the platform libraries...
Stuart Ballard, Senior Web Developer
(215) 283-2300, ext. 126