• Advertisement
Sign in to follow this  

[.net] Visual Basic .NET vs C#

This topic is 4378 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am pretty new to programming and know C/C++ and am currently learning Java. I have a friend who is interested in learning how to program games. He is currently learning Visual Basic in college. I was wondering if the speed of all .NET languages are the same. I am considering learning Visual Basic .NET in order to do a small project with him. Would Visual Basic have the speed enough to complete a MMORPG...j/k, a simple RPG? Any help would be great.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by nihonlvr
I was wondering if the speed of all .NET languages are the same.
C# and VB.NET are compiled into the same thing, so yes. It all comes down to personal choice.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I found that IL code, which .NET compilers create, is not optimal. It needs to do some optimization. And the speed of .Net applications is not so good with compare of unmanaged code i think.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rob Loach
Quote:
Original post by nihonlvr
I was wondering if the speed of all .NET languages are the same.
C# and VB.NET are compiled into the same thing, so yes. It all comes down to personal choice.


You know, I hear that a lot, and it doesn't really make any sense. C and VB4 also compiled to the same thing. I don't think anyone maintained any illusions. That said, VB.NET and C# have comparable ideologies and features, and the compn fact, in the original version of VS7, VB.NET was somewhat slower than C# because the C# compiler did a better job. Now that they have matured, the differences should be negligible. On the top of my head:

- C# is less verbose than VB.
- VB's intellisense is somewhat better.
- C# has a much better delegates syntax.
- C# is scheduled for interesting novelties in the next standard. Not sure about VB.
- VB has optional parameters and With blocks.
- C# has operator overloading.

Quote:
Original post by nihonlvr
Is it possible that .NET managed code will run a lot faster under Vista?


The word's on the street, altough I wouldn't expect any drastic change. But seriously, .NET languages are fast enough. Right now.

Share this post


Link to post
Share on other sites
Quote:
Original post by nihonlvr
Is it possible that .NET managed code will run a lot faster under Vista?


I wouldn't say 'a lot' but you can bet it will run faster. Maybe 10%, maybe not.
At the end of the day the speed of your app comes down to algorithm and memory managment choice (eg, sorting ,cache/GC usage, etc). If it's C++ or C# you likly will not see a difference. I've had apps I've ported from C++ to C# end up faster in C#, and also the odd one end up slower. In the grand scheme of things does 5% matter? No. I don't think it does.

There has been talk of intels next set of CPUs having instructions tailored to at least compiling .net code... Not so sure about actually running it. Which brings up a point to consider:
When we all finally do shift away from x86 architecture, your .net app will still run efficiently while your native C++ app may simply not run at all, or will require recompile/porting/emulation.

Quote:

I found that IL code, which .NET compilers create, is not optimal. It needs to do some optimization. And the speed of .Net applications is not so good with compare of unmanaged code i think.


*sigh*



ohh, yeah.

Good luck with your MMORPG :-) that made me smile it did

Share this post


Link to post
Share on other sites
Quote:
Original post by jfclavette
You know, I hear that a lot, and it doesn't really make any sense. C and VB4 also compiled to the same thing. I don't think anyone maintained any illusions. That said, VB.NET and C# have comparable ideologies and features, and the compn fact, in the original version of VS7, VB.NET was somewhat slower than C# because the C# compiler did a better job. Now that they have matured, the differences should be negligible. On the top of my head:

.....
Despite all of these differences, C# and VB.NET are both compiled into the same IL assembly, as the Anonymous Poster said.

One incorrect thing the AP said was that the speed of .NET applications was a lot slower when compared to unmanaged applications. If you take a look at this performance comparision between C++, C# and Java, you'll notice that C# is actually much faster in some instances. Even when it is slower, the difference is very minor.

Share this post


Link to post
Share on other sites
Quote:
Original post by jfclavette
You know, I hear that a lot, and it doesn't really make any sense. C and VB4 also compiled to the same thing. I don't think anyone maintained any illusions.

No, they didn't. VB4 compiled to p-code, not native code.

Share this post


Link to post
Share on other sites
As far as speed goes, JIT compiled code is extremely fast, not enough to care about. The speed hits come in when you're dealing with things like transitions from managed to unmanaged and back, marshalling, (maybe) mixed mode assemblies, and stuff like that. A lot of those problems will be sorted out with WinFX, but that's a while away.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I remember being able to configure whether to use natiive or pcode in vb4. Might have been vb6.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Native compilation wasn't added to VB until VB5.


I believe that was the common "include the runtime in the full assembly" bit that they are using for the java-to-native and the .net-to-native compilers.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Native compilation wasn't added to VB until VB5.


Right. I meant VB5. (Tough my memory still yells VB4 at me.)

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I found that IL code, which .NET compilers create, is not optimal. It needs to do some optimization. And the speed of .Net applications is not so good with compare of unmanaged code i think.


I'm willing to be you're wrong. :-)

In fact, depending on the application, managed code will run faster than unmanaged code (true, it's a corner case). Generally speaking, there _is_ a performance impact, but depending on usage, it's quite low. Definitely in the "under 10%" range. I've seen some REALLY poor performing managed code in my life though. But I've also seen some really poor performaing native apps too.

And as far as IL optimization goes -- by all means send your resume to Microsoft. The CLR team would love to hire extremely intelligent developers that know how to further optimize the compilation of IL into native code. Honestly.

Share this post


Link to post
Share on other sites
Quote:
Original post by nihonlvr
I was wondering if the speed of all .NET languages are the same.


Generally speaking, the answer is "yes". However, each language does some things in slightly different ways when it generates IL. The variance is diminishing with each iteration of the CLR though. In the end, what will really matter is the syntax that you prefer to work in, rather than the performance characteristics of each language.


Share this post


Link to post
Share on other sites
Quote:
Original post by dgweller
Quote:
Original post by Anonymous Poster
I found that IL code, which .NET compilers create, is not optimal. It needs to do some optimization. And the speed of .Net applications is not so good with compare of unmanaged code i think.


I'm willing to be you're wrong. :-)



I don't think he's entirely wrong - But it still doesn't matter :) - most of the actual optimizations are done at the JIT level - even though each language does emit slightly different IL (and again, the differences are usually so small as to be pretty much inconsequential), most serious optimizations will be done at JIT time, meaning that even non optimal JIT code will turn into very close to optimal machine code.

Btw, take what he said about submitting your resume seriously.

Share this post


Link to post
Share on other sites
They are practicaly the same once compiled to IL now. There used to be some small differences in the beginning but not anymore.

Share this post


Link to post
Share on other sites
This blog post seems to cover some of what we are discussing here. I thought I should share.

VB.NET and C# - Duplication of Effort?

His argues that both languages are becoming so similar that we might as well throw one out and focus on the other.

Quote:

I've always thought that the differences were just skins over IL myself.

Share this post


Link to post
Share on other sites
Really the only time IL is significantly less performant than a comparable native app is if the developer does not fully understand optimization tricks with managed code. It's the same thing with native apps, new developers to C++ can do some stupid things that compromise performance. If you have a .NET developer that fully understands the .NET runtime and memory management then they can build comparable managed counterparts to native apps.

And for the 100th reply, all .NET languages compile down to COMPARABLE IL, it's not the same, but it's close. Different language constructs can introduce less or more IL than another language, though it's generally not much of a concern.

~Graham

Share this post


Link to post
Share on other sites
If you are currently learning Java then go for C#.

Luck!
Guimo

Share this post


Link to post
Share on other sites
I think VB9 and C# 3 are actually diverging somewhat again, with VB9 gaining insane abilities with regards to type inference, unbelievably late binding, etc.

Share this post


Link to post
Share on other sites
Yeah, it was tricky to decide on the language when I accidently inspired someone to become a game developer, in the end I found a good C# 2.0 book for him on Amazon.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement