VB compiler VS CS compiler

D

Dave

I have recently moved from VB.NET to CS.NET to really learn the framework
and see what happens in a real OOP world! I am too happy with this move,
since it took me a very short time, to exploit CS as my new language of
choice, leaving VB.NET only for some UI creation. This said, i should
recommend that in spite of all words out there about the equality of these
two languages (which also means their managed applications), i have seen
much better performance in CS application than their VB.NET counter parts.
This is a very strange thing to note, since the differences observed in
performance were in pure arithmetic calculations, which had to be compiled
to the same IL and JITted with the same JITting machine. My Experiment
included a solution with the following VB and CS console applications:

CS project - Console Application:

/----------------------------------------------------------

using System;
class Class1
{
static void Main()
{
//Do the experiment three times
double total =0;
int cnt = 0;

for (cnt = 0; cnt < 20; cnt++)
{
DateTime t1 = DateTime.Now;

//The critical section:
for(int i=0; i<10000000; i++)
{
for(int j=0; j<100; j++)
{
long y ;
y = j;
}
}
/////////////////////////////
DateTime t2 = DateTime.Now;
TimeSpan t = t2 - t1;
Console.Write("The operation took: {0}\n", t.TotalMilliseconds);
total += t.TotalMilliseconds;
}
Console.WriteLine("\n--\nThe average time was: {0}\n", total / cnt);
Console.ReadLine();
}
}


//-----------------------------------------
CS properties:
Release mode
Optimize+
No check for arithmetic overflows

Average time took for critical operation: "2777.34375" milliseconds

*****************************************


VB Project - Console Application

'----------------------------------------------
Option Strict On
Option Explicit On

Module Module1

Sub Main()

Dim total As Double = 0
Dim cnt As Integer = 0

For cnt = 0 To 20

Dim t1 As DateTime = DateTime.Now

' The critical section
For i As Integer = 0 To 10000000
For j As Integer = 0 To 100
Dim y As Long
y = j
Next
Next
'''''''''''''''''''''''''''
Dim t2 As DateTime = DateTime.Now
Dim t As TimeSpan = t2.op_Subtraction(t2, t1)

Console.WriteLine("The operation took {0}", t.TotalMilliseconds)
total += t.TotalMilliseconds
Next

Console.WriteLine(vbCrLf & "The average time was: {0}", total / cnt)
Console.ReadLine()
End Sub

End Module


'--------------------------
VB project properties:

Release Mode
Optimize+
No check for arithmetic overflows

Average time took for critical operation: "3723.9583" milliseconds

**********************************

These tests were done on the following machine:
CPU: Intel Celeron 2.40 GHz
256 MB of RAM

..NET Framework 1.1
VS 2003
Win XP Pro SP2 with latest updates

No virus scanning running


Please tell me if i am wrong or sth. Otherwise please inform me what really
causes this.

Thanks in advance
 
P

Patrice

Check out the loops to make sure you are running the test the same number of
times...

--
 
A

Armin Zingler

Dave said:
CS project - Console Application:
Average time took for critical operation: "2777.34375" milliseconds

VB Project - Console Application
Average time took for critical operation: "3723.9583" milliseconds


With same code and settings:

C# version: 1605
VB.Net: 1619

(= equal)
CPU: Intel Celeron 2.40 GHz

Glad to see that my results come from an 1,4GHz AMD (XP1600+) here.


Did you choose "Start withouth debugging" from debug menu?

Armin
 
S

Steve Walker

Dave said:
I have recently moved from VB.NET to CS.NET to really learn the framework
and see what happens in a real OOP world! I am too happy with this move,
since it took me a very short time, to exploit CS as my new language of
choice, leaving VB.NET only for some UI creation. This said, i should
recommend that in spite of all words out there about the equality of these
two languages (which also means their managed applications), i have seen
much better performance in CS application than their VB.NET counter parts.
This is a very strange thing to note, since the differences observed in
performance were in pure arithmetic calculations, which had to be compiled
to the same IL and JITted with the same JITting machine. My Experiment
included a solution with the following VB and CS console applications:

I get:

C#: 1090 ms
VB: 1600 ms (with overflow checking)
VB: 1100 ms (without overflow checking)

Are you sure you had the "Remove integer overflow checks" box ticked?
 
D

Dave

Sorry! Seems like there was a problem with my VS
I have reinstalled VS:

Now the results are the same!
CS: 934.375
VB: 945.686

If you like to experiment more, port the CS application to a managed Cpp
application. The cool Cpp comiler seems to calculate the results in compile
time, because the release Cpp.NET application is as fast as lightning!
Try it....
 
D

Dave

Sorry! Seems like there was a problem with my VS
I have reinstalled VS:

Now the results are the same!
CS: 934.375
VB: 945.686

If you like to experiment more, port the CS application to a managed Cpp
application. The cool Cpp comiler seems to calculate the results in compile
time, because the release Cpp.NET application is as fast as lightning!
Try it....
 
L

Larry Lard

Dave said:
Sorry! Seems like there was a problem with my VS
I have reinstalled VS:

Now the results are the same!
CS: 934.375
VB: 945.686

If you like to experiment more, port the CS application to a managed Cpp
application. The cool Cpp comiler seems to calculate the results in compile
time, because the release Cpp.NET application is as fast as lightning!
Try it....


A good optimising compiler (I don't know enough to say if the C++.NET
compiler is such a beast) might well optimise your entire test into a
NOP, seeing as it doesn't actually do anything, and can be 'seen' to
not actualy do anything.

(pseudo-code)
A thousand million times do this:
Set a variable to a value, then throw away the variable
 
G

Guest

By the way, your C# version was doing many extra iterations since each of
your C# loops was cut short by 1 (this reduction in the outer loop alone
means that your C# version was running 5% fewer iterations).

i.e., "For cnt = 0 to 20" does 1 more iteration than "for (cnt = 0; cnt <
20; cnt++)"

David Anton
www.tangiblesoftwaresolutions.com
Home of the Instant C# VB.NET to C# converter
and the Instant VB C# to VB.NET converter
 
N

Nick Malik [Microsoft]

One minor comment:
I have recently moved from VB.NET to CS.NET to really learn the framework
and see what happens in a real OOP world!

Object oriented programming is not a gift from a language. It starts with a
set of constructs and stretches into the fundamental approach you use when
creating code. VB.Net is an OOP language. So is C#.

In fact, the commercial OO modeling tools and code generators that I am
familiar with will generate code in Java, C++, C#, VB.Net, and Smalltalk. .
All of these languages are Object Oriented. (there are other OO languages
from what I understand, but I don't think many folks are using them).

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
A

_AnonCoward

:
: In message <[email protected]>, Dave
: >I have recently moved from VB.NET to CS.NET to really learn the
: >framework and see what happens in a real OOP world! I am too happy
: >with this move, since it took me a very short time, to exploit CS
: >as my new language of choice, leaving VB.NET only for some UI
: >creation. This said, i should recommend that in spite of all words
: >out there about the equality of these two languages (which also means
: >their managed applications), i have seen much better performance in
: >CS application than their VB.NET counter parts. This is a very
: >strange thing to note, since the differences observed in performance
: >were in pure arithmetic calculations, which had to be compiled to the
: >same IL and JITted with the same JITting machine. My Experiment
: >included a solution with the following VB and CS console
: >applications:
:
: I get:
:
: C#: 1090 ms
: VB: 1600 ms (with overflow checking)
: VB: 1100 ms (without overflow checking)
:
: Are you sure you had the "Remove integer overflow checks" box ticked?
:
: --
: Steve Walker



That was my result as well. I compiled from the command line with the
following commands:

vbc /out:vb.exe tmp.vb
vbc /removeintchecks+ /out:vb.exe tmp.vb

In the former, I saw response times of 1700 ms give or take. With the
checks off, I saw response times in the 1000+/- ms range.


I also tried the CS version with these commands:

csc /out:cs.exe tmp.cs
csc /checked+ /out:cs.exe tmp.cs

The results were similar.


Ralf
 
A

_AnonCoward

:
: In message <[email protected]>, Dave
: >I have recently moved from VB.NET to CS.NET to really learn the
: >framework and see what happens in a real OOP world! I am too happy
: >with this move, since it took me a very short time, to exploit CS
: >as my new language of choice, leaving VB.NET only for some UI
: >creation. This said, i should recommend that in spite of all words
: >out there about the equality of these two languages (which also means
: >their managed applications), i have seen much better performance in
: >CS application than their VB.NET counter parts. This is a very
: >strange thing to note, since the differences observed in performance
: >were in pure arithmetic calculations, which had to be compiled to the
: >same IL and JITted with the same JITting machine. My Experiment
: >included a solution with the following VB and CS console
applications:
:
: I get:
:
: C#: 1090 ms
: VB: 1600 ms (with overflow checking)
: VB: 1100 ms (without overflow checking)
:
: Are you sure you had the "Remove integer overflow checks" box ticked?
:
: --
: Steve Walker



That was my result as well. I compiled from the command line with the
following commands:

vbc /out:vb.exe tmp.vb
vbc /removeintchecks+ /out:vb.exe tmp.vb

In the former, I saw response times of 1700 ms give or take. With the
checks off, I saw response times in the 1000+/- ms range.


I also tried the CS version with these commands:

csc /out:cs.exe tmp.cs
csc /checked+ /out:cs.exe tmp.cs

The results were similar.


Plz note that I changed the vb Module to a Class (and renamed Sub Main
to Public Shared Sub Main). I don't know if that made a difference, but
I wanted to make the two applications a similar as I could. In addition,
I increased the number of interations in the CS code as the [i = 0; i <
20; i++ ] block runs one fewer passes than [For i = 0 to 20]. That
mattered


While there are important differences between the two languages, I'm of
the opinion that for most situations the choice between which to use is
mostly a matter of personal taste.


Ralf
 
A

_AnonCoward

:
: In message <[email protected]>, Dave
: >I have recently moved from VB.NET to CS.NET to really learn the
: >framework and see what happens in a real OOP world! I am too happy
: >with this move, since it took me a very short time, to exploit CS
: >as my new language of choice, leaving VB.NET only for some UI
: >creation. This said, i should recommend that in spite of all words
: >out there about the equality of these two languages (which also means
: >their managed applications), i have seen much better performance in
: >CS application than their VB.NET counter parts. This is a very
: >strange thing to note, since the differences observed in performance
: >were in pure arithmetic calculations, which had to be compiled to the
: >same IL and JITted with the same JITting machine. My Experiment
: >included a solution with the following VB and CS console
applications:
:
: I get:
:
: C#: 1090 ms
: VB: 1600 ms (with overflow checking)
: VB: 1100 ms (without overflow checking)
:
: Are you sure you had the "Remove integer overflow checks" box ticked?
:
: --
: Steve Walker



That was my result as well. I compiled from the command line with the
following commands:

vbc /out:vb.exe tmp.vb
vbc /removeintchecks+ /out:vb.exe tmp.vb

In the former, I saw response times of 1700 ms give or take. With the
checks off, I saw response times in the 1000+/- ms range.


I also tried the CS version with these commands:

csc /out:cs.exe tmp.cs
csc /checked+ /out:cs.exe tmp.cs

The results were similar.


Plz note that I changed the vb Module to a Class (and renamed Sub Main
to Public Shared Sub Main). I don't know if that made a difference, but
I wanted to make the two applications a similar as I could. In addition,
I increased the number of interations in the CS code as the [i = 0; i <
20; i++ ] block runs one fewer passes than [For i = 0 to 20]. That
mattered


While there are important differences between the two languages, I'm of
the opinion that for most situations the choice between which to use is
mostly a matter of personal taste.


Ralf
 
D

Dave

Well, you can declare types in an interface in VB.NET, while it generates an
error in CS. Sth like an abstract class in an interface "(Mustinherit" in
VB)....So, i think wheher CS or VB is doing sth wrong here.
 
A

_AnonCoward

Can you give an example?


: Well, you can declare types in an interface in VB.NET, while it
: generates an error in CS. Sth like an abstract class in an interface
: "(Mustinherit" in VB)....So, i think wheher CS or VB is doing sth
: wrong here.
:
: : > I'm curious, what "real OOP" can you do in C# that can't be done in
: > VB.NET?
:
:
 
D

Dave

_AnonCoward said:
Can you give an example?

This is what i found in one of the posts to
microsoft.public.dotnet.languages.vb on Friday, April 15, 2005 3:12 PM

The following will compile in VB.NET 2003
-------------------------------------------------------

Public Interface IRenderable
Sub Render()
MustInherit Class Engine
MustOverride Sub TurnOn()
Interface IAutomatic
Sub Start()
End Interface
End Class
End Interface
 
N

Nick Malik [Microsoft]

how does this make C# a real OO language where VB.Net is not?

I see a minor language difference. I don't see something that prevents you
from describing VB as an OO language.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
C

Cor Ligthert

Dave,

I hope that I don't kick to many people with this message. In my opinion is
OO not direct programming related.

When there was 100 years ago a house build in my country, than most parts
were created on the place where the building would come.

Now they are designed first where as much elements from prefab classes are
used.

For me is that the essence of OOP. That there is syntax around it tells
nothing. The same as with building houses are (and should) the methods that
creates the classes every time be better and better.

Just my thought,

Cor
 
D

Dave

Cor Ligthert said:
Dave,

I hope that I don't kick to many people with this message. In my opinion
is OO not direct programming related.

When there was 100 years ago a house build in my country, than most parts
were created on the place where the building would come.

Now they are designed first where as much elements from prefab classes are
used.

For me is that the essence of OOP. That there is syntax around it tells
nothing. The same as with building houses are (and should) the methods
that creates the classes every time be better and better.

Just my thought,

Cor

You are right probably.... it might be a matter of personal taste. But
believe me, coming from the world of VB6 into VB.NET was not only a "shock",
but also the oop concepts were too odd to swallow. I couldn't really get
on it...There were all those powerful object facilities in VB.NET...
i just couldn't exploit them...maybe because of the background-VB syntax i
had
in my thinking patterns.
The change to C# for me was a way to pass over that obstacle. Everything is
where it has to be, the language is as brief and as original as possible...
and it is now that i am realizing what OOP really is and what goes on at the
heart of the
framework.

As i said...just my thought of course.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top