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

[Jonathan Shore]

Unfortunately this did not work.   There is something else blocking the inlining here.   I'll create a test for this ...

On Jul 17, 2012, at 10:41 AM, Rodrigo Kumpera wrote:

> 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
> 
> 	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/d6e76709/attachment-0001.html>