.NET Frameworks as C++ classes
-
Question: I'm I right in saying that the .NET framework DLLs are written using the CLR. Is this the above question is YES, then the .NET framework in general is going to be really slow. Why dont Microsoft also produce a C++ class version of the .NET, for extra performance. Regards A worried VC++ User :(
-
Question: I'm I right in saying that the .NET framework DLLs are written using the CLR. Is this the above question is YES, then the .NET framework in general is going to be really slow. Why dont Microsoft also produce a C++ class version of the .NET, for extra performance. Regards A worried VC++ User :(
Yes, I believe virtually all of the framework is written using C#. D
-
Question: I'm I right in saying that the .NET framework DLLs are written using the CLR. Is this the above question is YES, then the .NET framework in general is going to be really slow. Why dont Microsoft also produce a C++ class version of the .NET, for extra performance. Regards A worried VC++ User :(
I also believe they are primarily written in C#. It doesn't matter what language Microsoft uses for .NET, it's going to run in the Context of a managed environment. If C++ (not managed) is used, then we lose the benefits of the .NET framework such as garbage collection and language independence. Jason Gerard MCSD, MCSE Technology Point International, Inc.
-
Question: I'm I right in saying that the .NET framework DLLs are written using the CLR. Is this the above question is YES, then the .NET framework in general is going to be really slow. Why dont Microsoft also produce a C++ class version of the .NET, for extra performance. Regards A worried VC++ User :(
.NET has two core .DLLs: MSCOREE.DLL - is UNMANAGED runtime (most probably written in C++). This .DLL loads other .NET (managed) DLLs = assemblies and runs them. MSCORLIB.DLL - is most important MANAGED assembly containing core .NET types. Is MUST be written as managed code by design of .NET framework. Don't worry about performance. Managed code != slow code. In fact theoreticaly it can be faster than C++ code. Note, that C#, VB is compiled at runtime (JIT compilation). Performance will depend on quality of JIT compiler. It also means, that if you will buy new processor (P4, P5, P6...) new version of JIT optimized for this processor will provide faster code without any recompilation of your source code. And your old not optimized C++ code can be slower...
-
.NET has two core .DLLs: MSCOREE.DLL - is UNMANAGED runtime (most probably written in C++). This .DLL loads other .NET (managed) DLLs = assemblies and runs them. MSCORLIB.DLL - is most important MANAGED assembly containing core .NET types. Is MUST be written as managed code by design of .NET framework. Don't worry about performance. Managed code != slow code. In fact theoreticaly it can be faster than C++ code. Note, that C#, VB is compiled at runtime (JIT compilation). Performance will depend on quality of JIT compiler. It also means, that if you will buy new processor (P4, P5, P6...) new version of JIT optimized for this processor will provide faster code without any recompilation of your source code. And your old not optimized C++ code can be slower...
One core .NET DLL is written in C++, and the rest of the .NET DLL written as managed DLL. Pah! I'm no rocket scientist, but surely a desktop application written as a native C++ program has to far faster than any C# program. You say "In fact theoreticaly it can be faster than C++ code" - prove it. "It also means, that if you will buy new processor (P4, P5, P6...) new version of JIT optimized for this processor will provide faster code without any recompilation of your source code.". I tell my client (100+user) to go out and buy 100+ new machines, just because it will provide faster code, oh and this is only for Intel Processors ??? :| "And your old not optimized C++ code can be slower" - Hokey Dokey!, I'll scrap any systems developed in MFC and port them over to C# and pig will fly from my butt! You've obviously been sucked in by the M$ marketing bandwangon or in fact you are from Microsoft.
-
One core .NET DLL is written in C++, and the rest of the .NET DLL written as managed DLL. Pah! I'm no rocket scientist, but surely a desktop application written as a native C++ program has to far faster than any C# program. You say "In fact theoreticaly it can be faster than C++ code" - prove it. "It also means, that if you will buy new processor (P4, P5, P6...) new version of JIT optimized for this processor will provide faster code without any recompilation of your source code.". I tell my client (100+user) to go out and buy 100+ new machines, just because it will provide faster code, oh and this is only for Intel Processors ??? :| "And your old not optimized C++ code can be slower" - Hokey Dokey!, I'll scrap any systems developed in MFC and port them over to C# and pig will fly from my butt! You've obviously been sucked in by the M$ marketing bandwangon or in fact you are from Microsoft.
>> "It also means, that if you will buy new processor >> (P4, P5, P6...) new version of JIT optimized for >> this processor will provide faster code without >> any recompilation of your source code.". I tell my >> client (100+user) to go out and buy 100+ new >> machines, just because it will provide faster code, >> oh and this is only for Intel Processors ??? Ermmm.... Why would you go and get new machines just to get one program to run faster? Where was it said that you should do that? It's just one of the positive sides of the architecture - it means that instead of messing around changing int64s and other such things for the latest optimised compiler, the runtime does it for you. It would obviously be very stupid to purchase new machines just for the benefit of one program. It would only be worth doing if the whole .net architecture would be of use to your company/client. >> "And your old not optimized C++ code can be slower" >> - Hokey Dokey!, I'll scrap any systems developed in MFC >> and port them over to C# and pig will fly from my butt! >> You've obviously been sucked in by the M$ marketing >> bandwangon or in fact you are from Microsoft. WTF is your problem???? Optimised code in C++ will probably be faster than anything you can get in Java/C# even if that is optimised. But bth, it's like the old argument between ASM and C++. What's best for number crunching and memory management? ASM - but even for things like mp3 encoding and heavy number crunching, more and more people are using high level languages to make programs. But a lamely written C++ program could quite easily be slower than a well written c# program - not all the time, but the fact that C# is a simpler and more structured language in theory makes it easier to make well written programs. Have you even tried .NET? From your last sentence, I presume you haven't, but I've tried it and I'm using it, and I'm quite impressed with it. C# is not as fast as C++ - but unless you're doing number crunching it's unlikely your users will notice it's slower. I haven't noticed any problems with user interfaces in terms of response speed etc, and that's with a beta. Peter Pearson
-
>> "It also means, that if you will buy new processor >> (P4, P5, P6...) new version of JIT optimized for >> this processor will provide faster code without >> any recompilation of your source code.". I tell my >> client (100+user) to go out and buy 100+ new >> machines, just because it will provide faster code, >> oh and this is only for Intel Processors ??? Ermmm.... Why would you go and get new machines just to get one program to run faster? Where was it said that you should do that? It's just one of the positive sides of the architecture - it means that instead of messing around changing int64s and other such things for the latest optimised compiler, the runtime does it for you. It would obviously be very stupid to purchase new machines just for the benefit of one program. It would only be worth doing if the whole .net architecture would be of use to your company/client. >> "And your old not optimized C++ code can be slower" >> - Hokey Dokey!, I'll scrap any systems developed in MFC >> and port them over to C# and pig will fly from my butt! >> You've obviously been sucked in by the M$ marketing >> bandwangon or in fact you are from Microsoft. WTF is your problem???? Optimised code in C++ will probably be faster than anything you can get in Java/C# even if that is optimised. But bth, it's like the old argument between ASM and C++. What's best for number crunching and memory management? ASM - but even for things like mp3 encoding and heavy number crunching, more and more people are using high level languages to make programs. But a lamely written C++ program could quite easily be slower than a well written c# program - not all the time, but the fact that C# is a simpler and more structured language in theory makes it easier to make well written programs. Have you even tried .NET? From your last sentence, I presume you haven't, but I've tried it and I'm using it, and I'm quite impressed with it. C# is not as fast as C++ - but unless you're doing number crunching it's unlikely your users will notice it's slower. I haven't noticed any problems with user interfaces in terms of response speed etc, and that's with a beta. Peter Pearson
Peter >"Have you even tried .NET? From your last sentence, I presume you haven't, but >I've tried it and I'm using it, and I'm quite impressed with it. C# is not as >fast as C++ - but unless you're doing number crunching it's unlikely your users >will notice it's slower. I haven't noticed any problems with user interfaces in >terms of response speed etc, and that's with a beta." "I haven't noticed any problems with user interfaces in terms of response speed etc, and that's with a beta" Oh I really think you must be running your beta on a Cray Supercomputer, .Net runs like a pig on my machine (256Mb Ram, AMD950mhz), "and its not slow", pull the other one :| Anyway can't arsed arguing all day, I have _REAL_ applications to write in _REAL_ world, until VS7.0 is officially released and has been aired for a while, I wont be touching it, even for beta purposes. "and less of the WTF" :mad: Norm Almond Chief Technical Architect FS Walker Hughes Limited
-
I also believe they are primarily written in C#. It doesn't matter what language Microsoft uses for .NET, it's going to run in the Context of a managed environment. If C++ (not managed) is used, then we lose the benefits of the .NET framework such as garbage collection and language independence. Jason Gerard MCSD, MCSE Technology Point International, Inc.
-
Peter >"Have you even tried .NET? From your last sentence, I presume you haven't, but >I've tried it and I'm using it, and I'm quite impressed with it. C# is not as >fast as C++ - but unless you're doing number crunching it's unlikely your users >will notice it's slower. I haven't noticed any problems with user interfaces in >terms of response speed etc, and that's with a beta." "I haven't noticed any problems with user interfaces in terms of response speed etc, and that's with a beta" Oh I really think you must be running your beta on a Cray Supercomputer, .Net runs like a pig on my machine (256Mb Ram, AMD950mhz), "and its not slow", pull the other one :| Anyway can't arsed arguing all day, I have _REAL_ applications to write in _REAL_ world, until VS7.0 is officially released and has been aired for a while, I wont be touching it, even for beta purposes. "and less of the WTF" :mad: Norm Almond Chief Technical Architect FS Walker Hughes Limited
I think you're referring to VS .NET when you say ".Net runs like a pig". Please post some timings of actual .Net applications rather than just the IDE, which has so much debug code to be almost unuseable.
-
Peter >"Have you even tried .NET? From your last sentence, I presume you haven't, but >I've tried it and I'm using it, and I'm quite impressed with it. C# is not as >fast as C++ - but unless you're doing number crunching it's unlikely your users >will notice it's slower. I haven't noticed any problems with user interfaces in >terms of response speed etc, and that's with a beta." "I haven't noticed any problems with user interfaces in terms of response speed etc, and that's with a beta" Oh I really think you must be running your beta on a Cray Supercomputer, .Net runs like a pig on my machine (256Mb Ram, AMD950mhz), "and its not slow", pull the other one :| Anyway can't arsed arguing all day, I have _REAL_ applications to write in _REAL_ world, until VS7.0 is officially released and has been aired for a while, I wont be touching it, even for beta purposes. "and less of the WTF" :mad: Norm Almond Chief Technical Architect FS Walker Hughes Limited
>> "I haven't noticed any problems with user interfaces in terms >> of response speed etc, and that's with a beta" Oh I really >> think you must be running your beta on a Cray Supercomputer, >> .Net runs like a pig on my machine (256Mb Ram, AMD950mhz), >> "and its not slow", pull the other one :| Anyway can't arsed >> arguing all day, I have _REAL_ applications to write in >> _REAL_ world, until VS7.0 is officially released and has been >> aired for a while, I wont be touching it, even for beta >> purposes. Dual 933 actually, but my mistake - I meant the user interface of programs made with .NET - not the .NET interface itself - that *is* very slow - and the help is even slower. >> "and less of the WTF" No problem - but less of the quoting out of context. Cheers, Peter Pearson