Performance of VB.NET, C with various compilers

[singh]

Originally posted by: DaveSimmons
Nice job Kilrsat , and it looks like there is no penalty to using VB.Net these days, unlike older versions of VB where you gave up speed for the rapid development.

It would be naive to base such a broad conclusion on such a poor 'performance' test. The code used is not measuring language (or .NET vs. native) performance but rather FPU performance -- which should be identical in both native and .NET code. Let the op come up with a better test that involves abundant array access, recursive functions, large memory allocation and significant data structures. Then we can at least hope for a better comparison.

 

[igowerf]

You seem to get much bigger differences between Debug and Release modes than I did. Maybe the compiler is skipping the for loop in Release mode because the loop doesn't actually affect anything? Maybe it only actually calculated the for loop when you put the printf in.

 

[Brazen]

Originally posted by: xtknight
Kilrsat's code, Release config:

C .NET 2003 float: Operation completed in 19.344938 seconds (69246075.000000, 3579545).
C .NET 2003 double: Operation completed in 19.011113 seconds (68051134.000000, 3579545).
VB.NET 2003: Operation completed in 23.4601702171645 seconds.

I switched float i and float x,y to doubles. Is that what you meant?

I also have XP 64-bit VC.NET 2003 (native 64-bit) compile set up so I can try that as well. But only if somebody cares, because I'm lazy.

any chance of seeing this compiled on gcc?

 

[kamper]

Originally posted by: DaveSimmons

Originally posted by: kamper

Originally posted by: DaveSimmons
A very good compiler could throw away the loop entirely since you're only calling standard functions (no side effects) and never actually using x in or outside of the loop.

Just curious, wouldn't that require rolling out ~4million copies of the loop? Would it actually do that for such a big loop?

I'd also be curious to see the execution profiled, particularly to see how much of the time is spent in the actual math methods. It wouldn't surprise me if the .net versions were actually implemented natively anyways.

A good compiler could see that the calculation was never used, and so could throw the code away.

consider this:

x = 5;
x = 3;
x = 2;

A smart compiler would say the = 5 and = 3 lines have no effect on program state and are useless code that can be optimized away to just

x = 2;


that's why I suggested changing the x = assignment into a x += summation. To be safe also use the x outside of the loop in something like a cout or sprintf.

I get it

I like singh's suggestion of going with a slightly more complex test, as optimizations are too tricky to get reliable information from such a small test. Even then, we're never going to get anything more trustworth than "they're close".

 

[kamper]

I searched but couldn't find the thread that prompted this one (I was arguing about potential optimizations in a virtual machine) so I'll post this here, even though there hasn't been any java discussion in this thread.

This article goes into a little bit of detail about the things that a JIT can do to optimize that a static compiler can't. It doesn't go into extreme detail, like how a gc judges when an object is elligible for collection, but it's still interesting...

 

[xtknight]

Originally posted by: kamper
I searched but couldn't find the thread that prompted this one (I was arguing about potential optimizations in a virtual machine) so I'll post this here, even though there hasn't been any java discussion in this thread.

This article goes into a little bit of detail about the things that a JIT can do to optimize that a static compiler can't. It doesn't go into extreme detail, like how a gc judges when an object is elligible for collection, but it's still interesting...

That was some Java thread...

But that's interesting nonetheless.