Speed comparaison question

[nicolas.hilaire]

Hi all,

i need to choose a langage for porting my vb application to dot net 2.0
in november.

For some components, low-level components, i want to know if it can be
better to use specific .net language.

Basicaly, i want to know if
- managed c++ execution is faster than C# execution
- C# execution is faster than VB.Net execution

in fact, to know the speed classement between the languages using the
framework.net.. .
Thanks for your answers

Nicolas H.

[guy]

i havent used managed c++ but there is zero difference between VB.NET and C#,
the msil produced is near enough identical.
There are some performance advantages (!) in using VB.NET when it comes to
string handling etc, the VB.NET compiler can optimize Mid rather than using
substring but the end result is trivial.
choice of langauge is more a case of what you are used to, if you come from
a c++/java background go c#, if you are a VB person stick with vb.net

hth

guy

"ni************ *@motorola.com" wrote:

Hi all,

i need to choose a langage for porting my vb application to dot net 2.0
in november.

For some components, low-level components, i want to know if it can be
better to use specific .net language.

Basicaly, i want to know if
- managed c++ execution is faster than C# execution
- C# execution is faster than VB.Net execution

in fact, to know the speed classement between the languages using the
framework.net.. .
Thanks for your answers

Nicolas H.

[nicolas.hilaire]

ok, thanks a lot for your answer

I'm really interested with speed comparaison between managed C++ and C#
for example

i don't really think that managed C++ produced the same msil

If someone can answer this question, that would be great

thanks in advance

Nicolas H.

[Jon Skeet [C# MVP]]

guy <gu*@discussion s.microsoft.com > wrote:

i havent used managed c++ but there is zero difference between VB.NET and C#,
the msil produced is near enough identical.
No, it's not. There are a few cases where they generate different
enough IL that the JIT can inline the C# version but not the VB.NET
version. If you happen to be unlucky, that *could* make a significant
difference. Most of the time it wouldn't, but
There are some performance advantages (!) in using VB.NET when it comes to
string handling etc, the VB.NET compiler can optimize Mid rather than using
substring but the end result is trivial.

Do you have any examples of this? I believe Mid uses Substring
internally, so I don't see how it could be faster.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Jon,

No, it's not. There are a few cases where they generate different
enough IL that the JIT can inline the C# version but not the VB.NET
version. If you happen to be unlucky, that *could* make a significant
difference. Most of the time it wouldn't, but

Are you *100%* sure that a kind of this cannot be as well for VB.Net to C#?

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************ @planet.nl> wrote:

No, it's not. There are a few cases where they generate different
enough IL that the JIT can inline the C# version but not the VB.NET
version. If you happen to be unlucky, that *could* make a significant
difference. Most of the time it wouldn't, but

Are you *100%* sure that a kind of this cannot be as well for VB.Net to C#?

While I don't know every bit of IL that can be generated, I've only
heard about it (and tested it for myself) with the C# compiler
generating the leaner code (in terms of bytes of IL; there are more IL
instructions, but they're shorter). I also believe VB.NET adds NOPs in
when it doesn't need to in some situations. I should add that all this
is with 1.1 - the 2.0 JIT probably has different inlining rules, and
the compilers may well be generating different code anyway.

I'd be happy to be shown an example where the VB.NET IL is faster, of
course. I suspect that if they exist I'd have heard about them, but
that doesn't mean they definitely don't exist. (Note that my post
didn't claim they didn't exist, either.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[nicolas.hilaire]

this article is interesting
http://www.codeguru.com/columns/Kate/article.php/c5647/

but they don't talk about managed c++, which is my interest

Nicolas H.

[Cor Ligthert [MVP]]

Nicolas,

This is something done in long arguing in more dotnet newsgroups, where
often Jon (and Jay) and me were involved, while Jon mostly and I sometimes
did some testing.

If it is about constants, than concatinating is as we have seen quicker.

Be as well aware that running in the IDE can give an other performance
result than running it as exe.

I hope this gives an idea

Cor

[Jon Skeet [C# MVP]]

<ni************ *@motorola.com> wrote:

this article is interesting
http://www.codeguru.com/columns/Kate/article.php/c5647/

but they don't talk about managed c++, which is my interest

Shame it also misses the point of string.Concat, which is that it can
concatenate *multiple* strings in one call. Yet another article on
string performance which states a generality on the basis of one bad
usage...

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[nicolas.hilaire]

I suppose that managed c++ is the same speed when CLR objects are used,
but when it has native code, it should be as fast as before.

do you think the same / it's right ?
Nicolas H.