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 System.Xml.dll.
CC'ing mono-list for any insight they might have into why (or why not) you might want to AOT the platform libraries...
Stuart.
-- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
