🔒 Locked
.NET framework speed
Advertisement
Original Post
Ok, so theres this kid in my highschool programming couse. The teacher thinks hes the end all be all of programming. And were in this arguement, he keeps telling me that in the .NET framework c++ and VB are the same. I keep telling him that hes a moron and theres no way a compiled and interpreted language will be the same speed.
But he still wont listen. Hes adamant that they are the same speed. I told him that it may appear they are the same speed on small applications, but the little shit still thinks hes the greatest coder since Carmack.
So whos right and whos wrong? If Im wrong, Ill go apologize to him tomorrow at school.
,Matt
-= kill one your a murderer, kill thousands your a conquerer =-
I also heard that, basically, all the .NET application are the same, regardless of the language.
Height Map Editor | Eternal Lands | Fast User Directory
Height Map Editor | Eternal Lands | Fast User Directory
quote:
Original post by samosa
So whos right and whos wrong?
You are wrong. Managed C++ and VB.NET will run at approximately the same code, since they both compile to the same intermediate language - MSIL.
quote:
I keep telling him that hes a moron and theres no way a compiled and interpreted language will be the same speed.
VB.NET isn''t interpreted - it is compiled to MSIL, which is then Just-In-Time compiled to native X86 at load time.
...and that is why I believe linux must be destroyed.
But is the .NET standard MSIL code faster than the code that normal c++ would get compiled into? I believe that c++ with borland or other compliers is compiled into native code. Basically what Im asking is if .NET c++ slower or faster than non .NET code?
EDIT: also if they are the same speed then why arent game companies suddenly switching to game programming with VB, if theres no loss in speed isnt it an obvious choice?
,Matt
-= kill one your a murderer, kill thousands your a conquerer =-
[edited by - Samosa on May 11, 2003 12:05:09 AM]
EDIT: also if they are the same speed then why arent game companies suddenly switching to game programming with VB, if theres no loss in speed isnt it an obvious choice?
,Matt
-= kill one your a murderer, kill thousands your a conquerer =-
[edited by - Samosa on May 11, 2003 12:05:09 AM]
If you write good .NET code, you can have the program run as fast as a "oldschool" C++ program.
Just beware the load time, it's longer in .NET due to the JIT compile from MSIL to native code.
and for the "why don't they all switch to VB?" -- VB.NET is a completely different language than old VB. It now requires all of the type-declaration, nasty funk of the "real" languages, so with all of VB's long keywords (versus symbols), you end up having to type far more characters of code than with Managed C++ or C# (C# is my current favorite).
Which would you rather type if it end up being the same compiled result?
[edited by - Nypyren on May 11, 2003 12:09:22 AM]
Just beware the load time, it's longer in .NET due to the JIT compile from MSIL to native code.
and for the "why don't they all switch to VB?" -- VB.NET is a completely different language than old VB. It now requires all of the type-declaration, nasty funk of the "real" languages, so with all of VB's long keywords (versus symbols), you end up having to type far more characters of code than with Managed C++ or C# (C# is my current favorite).
if blarg then
end if
if (blarg)
{
}
Which would you rather type if it end up being the same compiled result?
[edited by - Nypyren on May 11, 2003 12:09:22 AM]
.NET is inherently slower than native C++.
Bur isn''t the .NET ''c++'' in fact c# ?
Height Map Editor | Eternal Lands | Fast User Directory
Bur isn''t the .NET ''c++'' in fact c# ?
Height Map Editor | Eternal Lands | Fast User Directory
quote:
Original post by Arild Fines
VB.NET isn''t interpreted - it is compiled to MSIL, which is then Just-In-Time compiled to native X86 at load time.
Whats the point? Why have VB and c++ compile into the same language then compile into native x86(assembly right?). Doesnt that just diminish c++''s speed?
,Matt
-= kill one your a murderer, kill thousands your a conquerer =-
.NET C++ is just plain old C++ with a few more keywords that let you use managed classes.
C# is a completely different language.
It's compiled into independant MSIL so that the JIT compiler can be processor/platform dependant, maybe optimizing for Pentium 4 or AMD specific stuff. Or maybe for linux if the people writing the JIT for linux are competent.
Maybe finally we can get rid of "#ifdef PROC_INTEL" forever.
[edited by - Nypyren on May 11, 2003 12:20:05 AM]
C# is a completely different language.
It's compiled into independant MSIL so that the JIT compiler can be processor/platform dependant, maybe optimizing for Pentium 4 or AMD specific stuff. Or maybe for linux if the people writing the JIT for linux are competent.
Maybe finally we can get rid of "#ifdef PROC_INTEL" forever.
[edited by - Nypyren on May 11, 2003 12:20:05 AM]
As far as I know there *is* a performance hit between the .net framework and "normal" compiled code. At the moment .net suffers a floating point/matrix bottleneck. Meaning that these operations are slower than "normal" compiled code. So if you have alot of these it will be slower.
Between languages in .net you will have differences in speed (maybe not really noticable but they will be there) Because the msil they make are *not* always equal. One good example of this is Boxing/unboxing in Managed C++ you do it by yourself so you can optimize it. In C# and VB the compiler does it itself. So if you are unaware of the boxing/unboxing your code will be different. You can manualy box/unbox in C# (don''t know about vb) but there is still other things the languages do different which will make the msil different.
Another thing is the longer the 2 apps are run the more they equal out (due to the cacheing(sp?)) of the program pieces in .net.
In the future .net may be as fast/faster than "normal" compiled code because of optimizations of the .net framework. As it is now though the .net framework *is* slower then "normal" compiled code. Depending on the app it may be noticable or not.
Between languages in .net you will have differences in speed (maybe not really noticable but they will be there) Because the msil they make are *not* always equal. One good example of this is Boxing/unboxing in Managed C++ you do it by yourself so you can optimize it. In C# and VB the compiler does it itself. So if you are unaware of the boxing/unboxing your code will be different. You can manualy box/unbox in C# (don''t know about vb) but there is still other things the languages do different which will make the msil different.
Another thing is the longer the 2 apps are run the more they equal out (due to the cacheing(sp?)) of the program pieces in .net.
In the future .net may be as fast/faster than "normal" compiled code because of optimizations of the .net framework. As it is now though the .net framework *is* slower then "normal" compiled code. Depending on the app it may be noticable or not.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement