Performance question regarding inlining of very simple struct methods

  • Thread starter Thread starter Fernando Cacciola
  • Start date Start date
F

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
 
Fernando said:
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?
Click to expand...

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.
 
mikeb said:
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.
Click to expand...
Ah! It must be that.. I run the code from within VS.NET.

Thanks!

Fernando Cacciola
 
Michael Culley said:
Did that make a difference?
Click to expand...
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
 
Fernando said:
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...
Click to expand...

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 ; }
Click to expand...

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?
Click to expand...

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.
 
mikeb said:
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.
Click to expand...
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.
Click to expand...
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.
I assume that the code for Same() is actually:

static public bool Same ( Col a, Col b ) { return a.mPtr == b.mPtr ; )
Click to expand...
oh, yes, of course
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.
Click to expand...
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
 
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
 
Back
Top