[Mono-dev] mono / llvm inlining situations (or failures thereof)

[Rodrigo Kumpera]

You can try a small trick to see if this is the case.

On your main function, before you go to that hot loop (it must be on a
separate function), you call into the vector code.

Eg:

static void Main () {
 new MathNet.Numerics.LinearAlgebra.Double.DenseVector (1); //or whatever
type you use.
 method_that_uses_it ();
}


If this works, then it would be interesting to see how MS get away with it.


On Tue, Jul 17, 2012 at 10:49 AM, Jonathan Shore
<jonathan.shore at gmail.com>wrote:

> Thanks, I have verified that the indexer below does not inline, even when
> setting MONO_INLINELIMIT.  Will try to construct a test case.
>
> I noticed that Vector<T> (from the OSS MathNet.Numerics project) does have
> 2 statically initialized values.  I am not sure if either of these would
> block inlining:
>
>
> http://mathnetnumerics.codeplex.com/SourceControl/changeset/view/b3dd68f35869#src%2fNumerics%2fLinearAlgebra%2fGeneric%2fVector.cs<http://mathnetnumerics.codeplex.com/SourceControl/changeset/view/b3dd68f35869#src/Numerics/LinearAlgebra/Generic/Vector.cs>
>
> private static readonly T Zero = default(T);
> private static readonly T One = Common.SetOne<T>();
>
> If these are the blockers and there is no reasonably simple way to
> address, I may have to switch matrix libraries.   Not being able to have
> inlined operations on the accessor reduces my performance by about 80% (my
> previous assessment of 25% was wrong).
>
>
> On Jul 16, 2012, at 2:45 PM, Rodrigo Kumpera wrote:
>
> You can use the MONO_VERBOSE_METHOD env var.
> It takes a method name but try a method spec to further narrow the massive
> JIT spew this produces if you have multiple matches.
>
>
> On Mon, Jul 16, 2012 at 3:29 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:
>
>>
>> On Jul 16, 2012, at 2:11 PM, Rodrigo Kumpera wrote:
>>
>>
>>
>> On Mon, Jul 16, 2012 at 2:45 PM, Jonathan Shore <jonathan.shore at gmail.com
>> > wrote:
>>
>>> Hi Rodrigo,
>>>
>>> I have played with the MONO_INLINELIMIT env variable (just discovered in
>>> the mono code a couple of days ago).  It solved some of my other inlining
>>> issues.   The AggressiveInlining option should be helpful for methods in
>>> 4.5 (I'm still on 4.0), though I don't believe the attribute can be used on
>>> properties, even though they are effectively methods (or am I wrong here).
>>>
>>
>>
>>> You mentioned "we don't inline methods that call other methods" and
>>> suggested might be the case in my code.   I am simply indexing the get
>>> method in:
>>>
>>> public override double this[int i]
>>> {
>>> get { return _data[i]; }
>>> set { _data[i]  = value; }
>>> }
>>>
>>> I thought that since this is an override, though on a leaf / sealed
>>> class, perhaps mono could not handle this case.   Not sure where indexing
>>> on this property would hit the "call another method" case.
>>>
>>
>> This should probably inline fine. Can you provide a small and complete
>> sample where this does happen? Your problem sounds really odd.
>>
>>
>> I did not try the MONO_INLINELIMIT with this particular problem.  I
>> manually inlined this one prior to posting and later applied the env
>> variable for a different inlining issue after posting.   It seems like the
>> default limit is perhaps too low (or too low for my application, I am OK
>> with using the env variable however).
>>
>> I'll reverse the change and give the env variable a go with the above.
>> Also, let me check the hierarchy of this class and see whether there is any
>> static construction.
>>
>> If there is nothing obvious, will try to arrange a test case over the
>> next few days.   Will be a bit tricky to arrange test, possibly, due to the
>> class environment.   With luck, can demonstrate with a simple test.
>>
>> Finally, how do I see the generated llvm x86 code.  Can I do this with
>> monodis?   I know I can see the IL   Thus far have been testing by noting
>> the runtime.
>>
>>
>>
>>
>>> If I understand this better, I can investigate / suggest some new
>>> feature re: inlining.
>>>
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120717/c4b632ad/attachment.html>