[Mono-dev] Long execution time on first execution (in AOT case)

[Zoltan Varga]

Hi,

   mono is designed to initialize most things lazily, so the first time <x>
is done, it will take more time. In particular, loading an aot image might
load it from disk, calling a pinvoke method
causes the shared libraries referenced by the pinvoke declaration to be
loaded from disk, etc.
Even calling a method does not initialize all the stuff needed by it, some
things will only be
initialized just before it is needed. So if you want to do soft real time
stuff, mono might not be
the perfect tool for that.

There are some steps that can be taken to decrease the latencies:
- For pinvoke, there is a Marshal.Prelink method which loads/looks up the
pinvoked function.
- For aot, the aot image is loaded when the corresponding assembly is
loaded.

                         Zoltan

On Tue, May 4, 2010 at 2:16 PM, Martin Däumler <mdae at cs.tu-chemnitz.de>wrote:

> Hello Mono developers,
>
>
> I need some help from Mono internals experts. Briefly speaking,
> I want to know exactly why the first execution of a code snippet,
> e.g., a P/Invoke, within Mono takes more time than the second run,
> especially in AOT case. First of all, I already read the AOT
> documentation [1]. I also tried to dive into the code and wrote
> some Mono tracing outputs ... but it is quite complex to select
> the necessary information from the whole chain of methods that
> keep Mono running.
>
> Source files for the example and information about the test system
> (for short: Linux on x86) can be downloaded under [2].
>
>   Let's examine a simple P/Invoke which is executed several times.
>   The invoked method just returns the method parameter's value. The
>   very first P/Invoke takes much more time (JIT: approx. 312 µs,
>   AOT: > 100 ms) than the following ones (JIT: 6 or 7 µs, AOT: < 1 µs)
>   on the test system. Test2 and Test3 are variants of Test1 which
>   demonstrate cache effects. However, the very first execution takes
>   longer in every case, so that's not all due to cache effects.
>
>
> I want to know how to make the execution of a code snippet/method
> deterministic, i.e., like C code can be deterministic, not necessarily
> "fast". That is, I tolerate a kind of "initialization" at startup time
> of Mono, but the first execution must not take (much) more time than
> following executions of the code snippet.
>
>
> In detail:
> ==========
>
>   - (How) Is it possible to load a AOT image completely into memory
>   (not just map into memory) before executing one of its methods?
>   Which function of Mono has to be called which way?
>
>   - (How) Is it possible to fill the GOT- and PLT-entries _before_
>   they are used the first time? Maybe a GOT-entry can not be
>   filled beforehand if a runtime object's address is not known at
>   startup time? Which function is called to do this
>   ( decode_patch_info()? )?
>
>   - Which additional functions have to be called when a AOT image's
>   method is executed the first time? I.e., how to get metadata
>   (mono_aot_get_class_info()?) or other necessary information/runtime
>   structures for the Mono runtime in advance?
>
>   - Are there any other functions that could cause longer execution
>   time on first execution?
>
>   - Any idea to measure execution time of managed code in granularity
>   of µs without using P/Invoke? The Environment.TickCount only provides
>   granularity of ms.
>
>   - Why is the execution of code snippets in a loop faster than
>   when rolling out the loop in the JIT case?
>
>   - Is it possible to JIT-compile all necessary wrapper methods
>   during the "initialization" (instead of porting Full AOT to
>   x86)? Note that AOTed wrapper methods (in the Full AOT case)
>   could also impose some overhead when starting first execution
>   since GOT- and/or PLT-entries have to be filled.
>
>
>
> With kind regards,
> Martin Däumler
>
>
> [1] http://mono-project.com/Mono:Runtime:Documentation:AOT
> [2] http://www.tu-chemnitz.de/~mdae/sample-code.zip
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100504/58c83c3c/attachment.html