Inline Attribute?

[Mike_R]

I guess this does not exist, but I'm hoping that there are some Attributes that can help direct how a Procedure is Optimized by the IL Assembler and/or JIT'er?

 

Here's the basic scenario, let's assume we have a double loop, something like this:

static void Proc1()
{
   for (int i = 0; i < 100; i++)
   {
       for (int j = 0; j < 100; i++)
       {
           // Your Code Here
           // Your Code Here
           // Your Code Here
       }
   }
}

However, I expect to actually utilize the inner-loop in a couple of different ways called in slightly different contexts. So I'm inclined to break it up as follows:

static void Proc1()
{
   for (int i = 0; i < 100; i++)
   {
       SubProc();
   }
}

static void SubProc()
{
   for (int j = 0; j < 100; i++)
   {
       // Your Code Here
       // Your Code Here
       // Your Code Here
   }
}

As for my coding, this 2nd variation would be better. The issue I have with this is that I need this to run fast. I realize that the extra stack-frame creation is rather small overhead... And the Compiler/Optimizer might actually Inline this for me anyway, so why worry? (It's a rather small/tight routine that I think would have a pretty good probability of being Optimized/Inlined.)

 

I was just wondering if there was an Attribute that could direct the Compiler to "Always Inline This Procedure"? I can force this myself with Copy-Paste, of course, but I'd really rather avoid the code replication in multiple locations.

 

I guess that a C-Style Macro Expansion would be another route for this? Does C# support that? However, I don't really love the "Macro-Expansion" concept; it just feels a little sloppy... And I'm using VB.Net anyway, so I'm sure that VB.Net can't do this.

 

I think the cleanest solution, really, would be an "Inline Attribute" if such a thing existed...

 

Any thoughts?

-- Mike

Edited February 26, 2005 by Mike_R

[PlausiblyDamp]

The JIT compiler will inline routines if it thinks there is a benefit, there is not way to influence it's decision through code. (Then again in C/C++ the inline keyword is fairly redundant as most compilers ignore it and make the decision themselves anyway).

C style #define macros are not supported (thank god) in either VB or C#.

IIRC there are some issues with how the JIT decides when it can / can't inline (these are being addressed in the 2005 as far as I am aware) but unless you are experiencing performance issues with this code I wouldn't be overly worried.

[Mike_R]

Ah, ok, that's great information to know. :)

 

Yeah, I'm not real worried, I doubt that I could even detect a difference... But if there were such an attribute, I can see why it could be useful. Funny that the compilers choose to ignore it anyway, but I can understand that as well...

 

I'm going to break up the code, but when I'm done, for kicks, I'll try a Copy-Paste version and time-test the difference. Something tells me that I won't be able to detect one... I'll report back if I find otherwise.

 

Thanks Plausibly, I really appreciate the feedback...

[michael_hk]

According to this article in MSDN, only small methods are inlined (IL size less than 32).

[snarfblam]

I don't see how it would make any sense to inline anything but small functions. In a large function the of the overhead of a function call is relatively tiny. Usually negligible. Although it is nice to now what the actual size limit is.

 

And the inline keyword in C++ always struck me as odd. Why include it in the language if it is simply ignored. Suppose it ought to be there just portability for those compilers that might actually use it, but the first tip of the day when you open Visual C++ should be "DON'T BOTHER USING INLINE! IT DOESN'T DO JACK!"

[Mike_R]

According to this article in MSDN' date=' only small methods are inlined (IL size less than 32).[/quote']Hey Michael,

 

Ok, that's very interesting... As it happens, my routine is under the wire at 24 lines. It's just a very tight loop:

Private Shared Function pvtChr_IsInCharList(ByVal chr As Char, _
                                           ByVal chrList As Char()) As Boolean
   For i As Integer = 0 To xmArray.Length(chrList) - 1
       If chr = chrList(i) Then
           Return True
       End If
   Next i
   Return False
End Function

It's such tight, obvious code that I don't mind replicating the code too much I guess. But I decided to wrap it within a function, I just prefer to not have the code replication and I call this at a number of points. If there were an <Inline()> Attribute, I would use it... But since it does not exist, I'll just have to to let the Compiler "do it's thing".

 

I personally think it has a pretty good shot at being in-lined anyway, but who knows? In the scheme of things and extra stack frame in the middle of text parsing is hardly worth worrying about, heh. It was just more of a theoretical question, I guess.

 

Thanks for that info. I've seen that writeup before, but I think I'll have to go give it another read. :)

Edited February 28, 2005 by Mike_R

[Mike_R]

I don't see how it would make any sense to inline anything but small functions. In a large function the of the overhead of a function call is relatively tiny. Usually negligible. Although it is nice to now what the actual size limit is.

 

And the inline keyword in C++ always struck me as odd. Why include it in the language if it is simply ignored. Suppose it ought to be there just portability for those compilers that might actually use it, but the first tip of the day when you open Visual C++ should be "DON'T BOTHER USING INLINE! IT DOESN'T DO JACK!"

Ok, well it being ignored, though frustrating to he programmer, does make sense. Who are "we" to decide what the optimum arrangement is? We might have some idea of the inner workings, but only the compiler itself can best make these decisions. So I can see the sense in it being ignored.

 

This has greater weight when one considers that the JIT'er is most definately going to evolve and improve over time... So for us to decide to Inline something today may make our <Inline()> Attribute meaningless or detrimental to the compiler tomorrow.

 

I'm curious about how this works in C++ anyway. Forget for the moment that it's *ignored* -- lol, tough to ignore -- but ignoring that, in C++ is this a sort of "Attribute" attached to the Proc() itself, or is this a modification to the Call, effectively something like 'Call Proc() Inline'.

 

It sounds like such *manual* Inline statements probably should not exist... but assuming one were to have them, I'm thinking that it makes more sense to tag the Call as "Inline" instead of tagging the Proc(), which would force it to always be Inline... But I don't know. I guess having both would give the most control.

 

Anyway, how does it work in C++? Is the Proc() tagged as "Inline" or is the Call tagged?

[michael_hk]

I personally think it has a pretty good shot at being in-lined anyway, but who knows? In the scheme of things and extra stack frame in the middle of text parsing is hardly worth worrying about, heh. It was just more of a theoretical question, I guess.

Yes, so inline or not, I will just let the compiler to decide.

[coldfusion244]

You have to figure when it is best to inline code. It's not worthless as others in this post have stated. The overhead of inlining a huge function sometimes isn't worth the cost. HOWEVER, if you are doing huge amount of branch prediction, it would be better to inline the code as to not through away the prefetch of the processor(if your function acts on already loaded data, etc). You just have to know when to use it. Also inlining will make your executable larger... programmers choice...

[Mike_R]

It sounds like in your hands it could be a very good tool... But in my hands it might not be such a good idea! :p

 

That's good info and makes sense. I wonder why the the C++ Inline calls are generally ignored then... I can think of two possible reasons:

 

(1) Overuse by noobs like me... and the compiler guys know it and so decide to ignore such use.

 

(2) No matter how good you are at knowing the compiler's innards, the complexity regarding optimal register usage etc. is really likely beyond what the C programmer can really know at run time... ASM would then be required to really nail this at this level.

 

But if you really know your stuff, I can see how an Inline call does make sense. Heck, I would use it on my little loop if I could... but maybe that would be the wrong call?

[coldfusion244]

C++ does include the _ASM directive... can't beat it if you want to make a simple calculator. That or encryption, why use >> or << when you can use xor, and, or, neg... Make use of that math co-processor!

[snarfblam]

Miker_R: About this...

I'm curious about how this works in C++ anyway. Forget for the moment that it's *ignored* -- lol, tough to ignore -- but ignoring that, in C++ is this a sort of "Attribute" attached to the Proc() itself, or is this a modification to the Call, effectively something like 'Call Proc() Inline'.

 

As far as C++, if a compiler actually uses your recommendation to inline here is the syntax:

inline void myfunction() {
   //Code goes here
}

 

It is a modifier of sorts (or "attribute" as you put it). It tells the compiler that instead of compiling it as a function at all, it should just be inserted everywhere the code calls this functions. So no, it is not used on a per-call basis.

 

But our cries to be inlined are ignored. The compiler knows best.

[Mike_R]

Ah, ok, cool I was curious about that, however "moot" this all is!

 

Thank guys. :)

[PlausiblyDamp]

IIRC Microsoft's C++ compiler does have a __forceinline (or similar) instruction which always inlines the code - can be useful if you do not want code to be in one single location (think serial number validation etc).

 

I remember reading on some MS blog or other that they are working on improving the JIT compiler in regards to what it can inline as well as making it look at larger methods as candidates for inlining (wish I could remember where I read it though...), guess we just have to sit and wait to see what happens.