Speed comparaison question

  • Thread starter Thread starter nicolas.hilaire
  • Start date Start date
N

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.
 
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
 
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.
 
guy said:
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,

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
 
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.)
 
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
 
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.
 
Back
Top