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

[Rodrigo Kumpera]

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120716/d4f6a1cc/attachment.html>