VB compiler VS CS compiler

[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

[Patrice]

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

--

"Dave" <Da*********@hotmail.com> a écrit dans le message de
news:ue**************@TK2MSFTNGP10.phx.gbl...

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

[Armin Zingler]

"Dave" <Da*********@hotmail.com> wrote

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

[Steve Walker]

In message <ue**************@TK2MSFTNGP10.phx.gbl>, Dave
<Da*********@hotmail.com> writes

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

[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....

"Armin Zingler" <az*******@freenet.de> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

"Dave" <Da*********@hotmail.com> wrote

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

[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....

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:mv**************@otolith.demon.co.uk...

In message <ue**************@TK2MSFTNGP10.phx.gbl>, Dave
<Da*********@hotmail.com> writes

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

[Larry Lard]

Dave wrote:

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....

"Armin Zingler" <az*******@freenet.de> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

"Dave" <Da*********@hotmail.com> wrote

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

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

--
Larry Lard
Replies to group please

[David Anton]

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

"Dave" wrote:

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

[David Anton]

Oops - I meant " your VB version was doing many extra iterations..."

"David Anton" wrote:

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

"Dave" wrote:

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

[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.
--
"Dave" <Da*********@hotmail.com> wrote in message
news:ue**************@TK2MSFTNGP10.phx.gbl...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

[_AnonCoward]

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:mv**************@otolith.demon.co.uk...
:
: In message <ue**************@TK2MSFTNGP10.phx.gbl>, Dave
: <Da*********@hotmail.com> writes
: >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

[_AnonCoward]

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:mv**************@otolith.demon.co.uk...
:
: In message <ue**************@TK2MSFTNGP10.phx.gbl>, Dave
: <Da*********@hotmail.com> writes
: >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

[_AnonCoward]

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:mv**************@otolith.demon.co.uk...
:
: In message <ue**************@TK2MSFTNGP10.phx.gbl>, Dave
: <Da*********@hotmail.com> writes
: >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

[Rob Windsor [MVP]]

I'm curious, what "real OOP" can you do in C# that can't be done in VB.NET?

--
Rob Windsor [MVP-VB]
G6 Consulting
Toronto, Canada
http://msmvps.com/windsor/
"Dave" <Da*********@hotmail.com> wrote in message
news:ue**************@TK2MSFTNGP10.phx.gbl...

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

[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.

"Rob Windsor [MVP]" <ro*****************@gmail.com> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

I'm curious, what "real OOP" can you do in C# that can't be done in
VB.NET?

[_AnonCoward]

Can you give an example?
"Dave" <Da*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
: 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.
:
: "Rob Windsor [MVP]" <ro*****************@gmail.com> wrote in message
: news:%2***************@TK2MSFTNGP15.phx.gbl...
: > I'm curious, what "real OOP" can you do in C# that can't be done in
: > VB.NET?
:
:

[Dave]

"_AnonCoward" <ab*@xyz.com> wrote in message
news:n9********************@twister.southeast.rr.c om...

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

--------------------------------

Do exactly the same thing in C#.NET 2003; it generates an error. It won't
compile.

[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.
--
"Dave" <Da*********@hotmail.com> wrote in message
news:uN***************@TK2MSFTNGP12.phx.gbl...

"_AnonCoward" <ab*@xyz.com> wrote in message
news:n9********************@twister.southeast.rr.c om...

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

--------------------------------

Do exactly the same thing in C#.NET 2003; it generates an error. It won't
compile.

[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

[Dave]

"Cor Ligthert" <no************@planet.nl> wrote in message
news:Ob*************@TK2MSFTNGP12.phx.gbl...

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.

[Xepol]

> for (cnt = 0; cnt < 20; cnt++)

this loop runs from 0 to 19, 20 itterations.

For cnt = 0 To 20

This loop runs from 0 to 20, 21 itterations.

All of your loops have this flaw, something to watch out for as in the case
of your test, the problem in each loop level tends to build up exponentially,
in this case you would be running about 100*10000000 extra loops in your VB
code, obviously not good for comparisons (and flat out evil if you are trying
to exactly reproduce code).

For cnt = 0 to 20 is equivalent to for (int cnt=0; cnt<=20; cnt++)

Moving from a 1 based universe to a zero based universe can be annoying
(every time I move from delphi strings to c strings it gives me a headache),
but you gotta watch those details.

- Clinton R. Johnson