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

[Leszek Ciesielski]

On Mon, Jul 16, 2012 at 6:20 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:
> Hi Jonathan,
>
> There are a few factors that affect inlining.
>
> We don't inline more than 10 levels deep, but I doubt this is your problem.
> We don't inline synchronized methods, methods that belong to MarshalByRef
> classes or method that do exception handlibg. Not your case, probably.
> We only inline methods smaller than 20bytes of IL. It might be your case.
> You can control this with the MONO_INLINELIMIT env var or use the
> AgressiveInlining compiler hint.
> We don't inline calls to classes that need their class constructor to be
> ran. Might be your case.
> We don't do inlining when generics are involved. Doesn't look to be your
> case;
> And, finally, we don't inline methods that call other methods (including
> constructors).
>
> The last restriction does look to be your issue. We do it due to a pair of
> issues, first because it produces broken stacktraces
> and because it breaks calls that check caller assembly. Both can be fixed if
> mono had support for inlining maps.

If that restriction is a major issue - doesn't the JVM solution work
good enough here? Just leave enough frames on the stack that
inter-assembly calls are interweaved as they should, leaving one frame
per assembly in the extreme case. Or is that a more complicated issue
than Java has with inlining?

>
> My suggestion is that you play with MONO_INLINELIMIT and AgressiveInlining.
> This can be reported as a feature request.
> I would love to see this done.
>
> Regards,
> Rodrigo
>
> On Sat, Jul 14, 2012 at 9:36 PM, Jonathan Shore <jonathan.shore at gmail.com>
> wrote:
>>
>>
>> I have a significant # of numerical routines that make use of vectors,
>> matrices, etc.   I have observed that mono --llvm does seem not inline
>> access in some situations where it reasonably could.   This means for a
>> difference in performance of about 25% in my code.
>>
>> I am using a 3rd party library for vector / matrix functionality that has
>> a generic class  Vector<T>.   I have created a number of specializations of
>> this class, such as:
>>
>> class SpecialVector : Vector<double>
>> {
>> ...
>> public override double this[int i]
>> {
>> get { return _data[i]; }
>> set { _data[i] = value; }
>> }
>>
>> public override double[] Data
>> { get { return _data; } }
>>
>> ...
>>
>> private double[] _data;
>> }
>>
>>
>> I have a rather tight-looped numerical algorithm on a number of these
>> vectors.  Such as:
>>
>> for (int i = 0 ; i < len ; i++)
>> {
>> var x = x[i];
>> ...
>> for (int k = ileft; k <= iright; k++)
>> {
>> var xk = x[k];
>> var yk = y[k];
>> ..
>> }
>> ...
>> }
>>
>> Where,  x and y are instances of these vectors.   x[i] and y[i] call the
>> this[int] accessor on their respective vectors.   Vector<double> defines
>> double this[int i] as a virtual function.
>>
>> SpecialVector is a sealed class, however.   Nevertheless, I realize a 25%
>> increase in performance if I do the following:
>>
>> var vx = x.Data;
>> var vy = y.Data;
>> for (int i = 0 ; i < len ; i++)
>> {
>> var x = vx[i];
>> ...
>> for (int k = ileft; k <= iright; k++)
>> {
>> var xk = vx[k];
>> var yk = vy[k];
>> ..
>> }
>> ...
>> }
>>
>> I suspect that mono / LLVM is not attempting inline this[int i] since is a
>> virtual method, in spite of being trivially determined to be leaf class.  OR
>> is there another reason why this is not inlined?
>>
>> Should this be reported as a bug or feature request?
>>
>> Thanks
>>
>> Jonathan
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>