Performance question regarding inlining of very simple struct methods

[Fernando Cacciola]

Hi, I'm terribly new at C# (come from C++ land).
I'm making some benchmarks to see the effect of different coding styles, and
I run across a situation that strikes me as pretty odd.

For my image processing code I would like to use low-level "Iterators", as I
would in C++, so I have a struct of the form:

public unsafe struct Col
{
public Col ( byte* ptr ) { mPtr = ptr ; }
static public bool Same( Col a, Col b ) { return a.mPtr == b.mPtr ; }
public void MoveRight() { mPtr += 3 ; }
public byte* mPtr ;
}

And a loop that looks like:

while ( !Col.Same(col_beg,col_end) )
//while ( col_beg.mPtr != col_end.mPtr )
{
.... some code here...
col_beg.MoveRight();
//col_beg.mPtr += 3 ;
}

I'm compiling with Optimizations on, (with TRACE but no DEBUG) and using
QueryPerformanceCounter() to measure execution time in ms.

If, for the while expression, I use the method 'Same', it takes about 2.7
seconds to complete a loop, but if I use direct comparison (see the
commented code right below), it takes about .58 seconds.
Likewise, using MoveRight() instead of the direct pointer addition takes 2.2
seconds with the direct pointer comparison for the while (that is, using the
configuration that took .58s and replacing only MoveRight())

Both MoveRight() and Same() are the kind of simple methods that I would have
expected the JIT to inline, so I'm kind of furstated by these results. Is
there any compiler options or switch or keyword I should have used?

TIA

Fernando Cacciola

[mikeb]

Fernando Cacciola wrote:

Hi, I'm terribly new at C# (come from C++ land).
I'm making some benchmarks to see the effect of different coding styles, and
I run across a situation that strikes me as pretty odd.

For my image processing code I would like to use low-level "Iterators", as I
would in C++, so I have a struct of the form:

public unsafe struct Col
{
public Col ( byte* ptr ) { mPtr = ptr ; }
static public bool Same( Col a, Col b ) { return a.mPtr == b.mPtr ; }
public void MoveRight() { mPtr += 3 ; }
public byte* mPtr ;
}

And a loop that looks like:

while ( !Col.Same(col_beg,col_end) )
//while ( col_beg.mPtr != col_end.mPtr )
{
.... some code here...
col_beg.MoveRight();
//col_beg.mPtr += 3 ;
}

I'm compiling with Optimizations on, (with TRACE but no DEBUG) and using
QueryPerformanceCounter() to measure execution time in ms.

If, for the while expression, I use the method 'Same', it takes about 2.7
seconds to complete a loop, but if I use direct comparison (see the
commented code right below), it takes about .58 seconds.
Likewise, using MoveRight() instead of the direct pointer addition takes 2.2
seconds with the direct pointer comparison for the while (that is, using the
configuration that took .58s and replacing only MoveRight())

Both MoveRight() and Same() are the kind of simple methods that I would have
expected the JIT to inline, so I'm kind of furstated by these results. Is
there any compiler options or switch or keyword I should have used?
Are you running your tests inside of VS.NET? If so, the JIT is not
performing any optimizations, even when you've compiled with
optimizations and you're not using the debugger.

Rerun your tests outside of VS.NET, see if that makes any difference.

TIA

Fernando Cacciola

--
mikeb

[Fernando Cacciola]

"mikeb" <ma************@mailnull.com> escribió en el mensaje
news:ui**************@TK2MSFTNGP11.phx.gbl...

Fernando Cacciola wrote:

Hi, I'm terribly new at C# (come from C++ land).
I'm making some benchmarks to see the effect of different coding styles, and I run across a situation that strikes me as pretty odd.

For my image processing code I would like to use low-level "Iterators", as I would in C++, so I have a struct of the form:

public unsafe struct Col
{
public Col ( byte* ptr ) { mPtr = ptr ; }
static public bool Same( Col a, Col b ) { return a.mPtr == b.mPtr ; } public void MoveRight() { mPtr += 3 ; }
public byte* mPtr ;
}

And a loop that looks like:

while ( !Col.Same(col_beg,col_end) )
//while ( col_beg.mPtr != col_end.mPtr )
{
.... some code here...
col_beg.MoveRight();
//col_beg.mPtr += 3 ;
}

I'm compiling with Optimizations on, (with TRACE but no DEBUG) and using
QueryPerformanceCounter() to measure execution time in ms.

If, for the while expression, I use the method 'Same', it takes about 2.7 seconds to complete a loop, but if I use direct comparison (see the
commented code right below), it takes about .58 seconds.
Likewise, using MoveRight() instead of the direct pointer addition takes 2.2 seconds with the direct pointer comparison for the while (that is, using the configuration that took .58s and replacing only MoveRight())

Both MoveRight() and Same() are the kind of simple methods that I would have expected the JIT to inline, so I'm kind of furstated by these results. Is there any compiler options or switch or keyword I should have used?

Are you running your tests inside of VS.NET? If so, the JIT is not
performing any optimizations, even when you've compiled with
optimizations and you're not using the debugger.

Rerun your tests outside of VS.NET, see if that makes any difference.

Ah! It must be that.. I run the code from within VS.NET.

Thanks!

Fernando Cacciola

[Michael Culley]

"Fernando Cacciola" <fe***************@hotmail.com> wrote in message news:Ol*************@TK2MSFTNGP10.phx.gbl...

Ah! It must be that.. I run the code from within VS.NET.

Did that make a difference?

--
Michael Culley

[Fernando Cacciola]

"Michael Culley" <mc*****@NOSPAMoptushome.com.au> escribió en el mensaje
news:O1**************@TK2MSFTNGP10.phx.gbl...

"Fernando Cacciola" <fe***************@hotmail.com> wrote in message

news:Ol*************@TK2MSFTNGP10.phx.gbl...

Ah! It must be that.. I run the code from within VS.NET.

Did that make a difference?

Not really....

Simply changing this
while ( col_beg.mPtr != col_end.mPtr )

with this
while ( !Col.Same(col_beg,col_end) )

makes the ellapsed time rise from about 2400 to 4400...

with

static public bool Same ( Col a, Col b ) { return a.mPtr != b.mPtr ; }

(I tried with 'ref' parameters too but that made no difference)

Any other idea? Or is it just that the JIT can't inline the simplest of the
functions?

Fernando Cacciola

[mikeb]

Fernando Cacciola wrote:

"Michael Culley" <mc*****@NOSPAMoptushome.com.au> escribió en el mensaje
news:O1**************@TK2MSFTNGP10.phx.gbl...

"Fernando Cacciola" <fe***************@hotmail.com> wrote in message
news:Ol*************@TK2MSFTNGP10.phx.gbl...

Ah! It must be that.. I run the code from within VS.NET.

Did that make a difference?

Not really....

Simply changing this
while ( col_beg.mPtr != col_end.mPtr )

with this
while ( !Col.Same(col_beg,col_end) )

makes the ellapsed time rise from about 2400 to 4400...

It seems to have a made a difference comparing numbers that you posted
in your first post and here. In your first post you were describing
timings that differed approximately 400% (2.7 vs. .58 seconds and 2.2
vs. .58 seconds). In this post, the numbers indicate about a 200%
difference.

I understand that this is still not as close as it should be, but it is
an indication that running outside of the VS.NET environment does make a
difference on the JIT output.

with

static public bool Same ( Col a, Col b ) { return a.mPtr != b.mPtr ; }

I assume that the code for Same() is actually:

static public bool Same ( Col a, Col b ) { return a.mPtr == b.mPtr ; )

(I tried with 'ref' parameters too but that made no difference)

Any other idea? Or is it just that the JIT can't inline the simplest of the
functions?

Finally, in looking over your original post, I noticed this time that
your Col struct is 'unsafe'. I wonder if the JIT does not inline unsafe
code, even if it could correctly do so.
Fernando Cacciola

--
mikeb

[Fernando Cacciola]

"mikeb" <ma************@mailnull.com> escribió en el mensaje
news:OQ**************@TK2MSFTNGP11.phx.gbl...

Fernando Cacciola wrote:

"Michael Culley" <mc*****@NOSPAMoptushome.com.au> escribió en el mensaje
news:O1**************@TK2MSFTNGP10.phx.gbl...

"Fernando Cacciola" <fe***************@hotmail.com> wrote in message
news:Ol*************@TK2MSFTNGP10.phx.gbl...

Ah! It must be that.. I run the code from within VS.NET.

Did that make a difference?

Not really....

Simply changing this
while ( col_beg.mPtr != col_end.mPtr )

with this
while ( !Col.Same(col_beg,col_end) )

makes the ellapsed time rise from about 2400 to 4400...

It seems to have a made a difference comparing numbers that you posted
in your first post and here. In your first post you were describing
timings that differed approximately 400% (2.7 vs. .58 seconds and 2.2
vs. .58 seconds). In this post, the numbers indicate about a 200%
difference.

Yes, very good point.
I understand that this is still not as close as it should be, but it is
an indication that running outside of the VS.NET environment does make a
difference on the JIT output.
Right. I expected to see a similar performance, but as you say, there's no
doubt that running outside the IDE makes a big difference.

with

static public bool Same ( Col a, Col b ) { return a.mPtr != b.mPtr ; }

I assume that the code for Same() is actually:

static public bool Same ( Col a, Col b ) { return a.mPtr == b.mPtr ; )

oh, yes, of course

(I tried with 'ref' parameters too but that made no difference)

Any other idea? Or is it just that the JIT can't inline the simplest of the functions?

Finally, in looking over your original post, I noticed this time that
your Col struct is 'unsafe'. I wonder if the JIT does not inline unsafe
code, even if it could correctly do so.

Good point.
I'll keep looking.
Maybe there are other factors like GC or so being involved.
I'll try to code a better benchmark interleaving both versions to account
for GC interruptions and other subtelties.

I'll get back with the new results.

Thanks

Fernando Cacciola

[Fernando Cacciola]

Well, it turned out that there was something getting in the way of my
previous benchmarks.
I rewrote it, and running from outside VS.NET I could see that there's no
performance penalty for such tiny easy to inline functions after all.
I tried with properties (both get/set), static/non-static methods and
trivial constructors.: they all seems to be properly inlined as I expected.

Thanks

Fernando Cacciola