Inline MSIL?

[Chris LaJoie]

Is it possible to use 'inline' MSIL (Intermediate Language) similar to how
you can use inline assembly in C/C++? If not, how can I include some code
written in IL in my project? Thanks,

Chris LaJoie

[Mattias Sjögren]

Chris,

.method private hidebysig static int32 Add(int32 op1,int32 op2)
{
.locals init (int32 retval)
IL_0000: ldarg.0
IL_0001: ldarg.1
IL_0002: add
IL_0003: stloc.0
IL_0004: br.s IL_0006

IL_0006: ldloc.0
IL_0007: ret
}

Surely you're looking at a non-optimized debug build? Compile with /o
and look again, the C# compiler can definitely do better than this.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/
Please reply only to the newsgroup.

[Lloyd Dupont]

BTW it doesn't compile at runtime everytime.
there is different policy on when a given method or assembly or method
should be compiled (you could choose but I don't remember how) however each
method is compiled only once and cached.

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:uu******** ******@TK2MSFTN GP10.phx.gbl...

Chris,

.method private hidebysig static int32 Add(int32 op1,int32 op2)
{
.locals init (int32 retval)
IL_0000: ldarg.0
IL_0001: ldarg.1
IL_0002: add
IL_0003: stloc.0
IL_0004: br.s IL_0006

IL_0006: ldloc.0
IL_0007: ret
}

Surely you're looking at a non-optimized debug build? Compile with /o
and look again, the C# compiler can definitely do better than this.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/
Please reply only to the newsgroup.

[Jon Skeet]

Lloyd Dupont <net.galador@ld > wrote:

BTW it doesn't compile at runtime everytime.
there is different policy on when a given method or assembly or method
should be compiled (you could choose but I don't remember how) however each
method is compiled only once and cached.

I don't believe that's true. I believe that unless you specifically
ngen the assembly, the JITted code won't be stored on disk anywhere.
(It's cached within the lifetime of the app, of course, but that's a
different matter.)

In a future version it *could* cache the code, of course, but I don't
believe it does at the moment.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

Chris LaJoie <ch***@etriptra der.com> wrote:

<snip>

that's a ratio of 8 lines vs. my 4 lines. Which one will be faster?

Just for fun, I *did* actually benchmark this - and to my surprise,
your version *was* faster (over 1000000000 iterations, it took about
3.5s as opposed to 6.3 for the original). I'm very surprised that the
JITter couldn't figure the two out to be identical.

However, I got almost exactly the same benefit by moving the hand-
optimized code into a separate DLL. It means it needs to be public,
which isn't terribly pleasant, but it's unlikely that there will be
many routines which actually *do* benefit significantly from this kind
of approach (and only those which actually *are* bottlenecks in the
app) so this shouldn't be needed very often.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

Jon,
See inline ****

Willy.

"Jon Skeet" <sk***@pobox.co m> wrote in message news:MP******** *************** *@news.microsof t.com...

Lloyd Dupont <net.galador@ld > wrote:

BTW it doesn't compile at runtime everytime.
there is different policy on when a given method or assembly or method
should be compiled (you could choose but I don't remember how) however each
method is compiled only once and cached.

*** I guess OP meant, cached in memory which is correct.
I don't believe that's true. I believe that unless you specifically
ngen the assembly, the JITted code won't be stored on disk anywhere.
(It's cached within the lifetime of the app, of course, but that's a
different matter.)

In a future version it *could* cache the code, of course, but I don't
believe it does at the moment.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Chris LaJoie]

Interresting test Jon. A few days ago I benchmarked our program's functions
written in C# (compiled with /o) against the ones written in IL and got
similar results. My IL code was nearly twice as fast. I would post the
code for you to see and test, but I don't want to give out company code and
risk losing my job. ;)

I believe that inline IL would be invaluable in situations where speed is
essential, and the C# compiler isn't compiling it in the most efficient way.
I plan on writing up a formal request/suggestion regarding inline IL in .NET
languages to Microsoft. I value your input and I'd like to ask your opinion
on this. Do you believe this would be a valuable addition, or am I wasting
my time?

Thanks,
Chris LaJoie
"Jon Skeet" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@news.microsof t.com...

Chris LaJoie <ch***@etriptra der.com> wrote:

<snip>

that's a ratio of 8 lines vs. my 4 lines. Which one will be faster?

Just for fun, I *did* actually benchmark this - and to my surprise,
your version *was* faster (over 1000000000 iterations, it took about
3.5s as opposed to 6.3 for the original). I'm very surprised that the
JITter couldn't figure the two out to be identical.

However, I got almost exactly the same benefit by moving the hand-
optimized code into a separate DLL. It means it needs to be public,
which isn't terribly pleasant, but it's unlikely that there will be
many routines which actually *do* benefit significantly from this kind
of approach (and only those which actually *are* bottlenecks in the
app) so this shouldn't be needed very often.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Michael Roper]

Chris LaJoie writes:

Interresting test Jon. A few days ago I benchmarked
our program's functions written in C# (compiled with /o)
against the ones written in IL and got similar results.

I'm new, but it certainly seems that compiler/jitter aren't very good. The
example given earlier was particularly striking. Is there an expectation
that they'll get better, soon? Are there competing products that do a
better job?

An inline feature would be nice, but it would be even better to have a
competent compilation in the first place.

Michael Roper

[Chris LaJoie]

Michael,
The code you saw earlier was not optimized code. I'm not entirely sure what
the code would look like if it was optimized, but I can tell you that for
the most part, the C# (or VB) compiler does an awesome job.

You have probably heard that assembly is faster than C/C++, but do you know
why? It's because the human mind is much more inventive and can think about
problems in many different ways to come up with the best/fastest solution.
A compiler has limitations. Someone please jump in if I'm wrong, but this
is how I look at it.

The only time I would ever write in a 'low-level' language like IL is if
speed was very important (which isn't very often). It's only these rare
situations that I believe IL would be invaluable.
Chris LaJoie

"Michael Roper" <mi******@encra ft.com> wrote in message
news:bj******** ****@ID-160215.news.uni-berlin.de...

Chris LaJoie writes:

Interresting test Jon. A few days ago I benchmarked
our program's functions written in C# (compiled with /o)
against the ones written in IL and got similar results.
I'm new, but it certainly seems that compiler/jitter aren't very good.

The example given earlier was particularly striking. Is there an expectation
that they'll get better, soon? Are there competing products that do a
better job?

An inline feature would be nice, but it would be even better to have a
competent compilation in the first place.

Michael Roper

[Jon Skeet]

Chris LaJoie <ch***@etriptra der.com> wrote:

Interresting test Jon. A few days ago I benchmarked our program's functions
written in C# (compiled with /o) against the ones written in IL and got
similar results. My IL code was nearly twice as fast. I would post the
code for you to see and test, but I don't want to give out company code and
risk losing my job. ;)
Understandable :)
I believe that inline IL would be invaluable in situations where speed is
essential, and the C# compiler isn't compiling it in the most efficient way.
I plan on writing up a formal request/suggestion regarding inline IL in .NET
languages to Microsoft. I value your input and I'd like to ask your opinion
on this. Do you believe this would be a valuable addition, or am I wasting
my time?

I would personally rather MS spent the time on improving the
compiler/jitter to come up with the same kind of code to start with -
that would give a bigger bang for the buck, I believe. I'd rather not
*have* to resort to IL for the kind of method you showed before.

On the other hand, they've already got the assembler itself - maybe it
wouldn't be a bad idea (especially as there are things you can do with
IL that you can't do in C#, as mentioned before). I think I'd probably
suggest making it pretty limited though: rather than inline IL within a
method, keep it to a per-method basis. That would mean it could stick
with the current IL without anyone having to worry about which
parameter/local variable corresponded with which IL stack variable,
etc.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Magnus Lidbom]

"Chris LaJoie" <ch***@etriptra der.com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Michael,
The code you saw earlier was not optimized code. I'm not entirely sure what
the code would look like if it was optimized,

..method private hidebysig static int32 Add(int32 op1,
int32 op2) cil managed
{
// Code size 4 (0x4)
.maxstack 2
IL_0000: ldarg.0
IL_0001: ldarg.1
IL_0002: add
IL_0003: ret
} // end of method Test::Add

Looks sort of familiar to me ;)

<SNIP>

/Magnus Lidbom