Click here to Skip to main content
15,352,714 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
Recently, I am starting to design an application for analysis and design structures with Finite Element method (FEM). Yet, I write my other previous application with VB.Net. But this new application need to a fast language because of huge matrix operation in FEM. It seems that visual c++ (.Net) is faster than VB.Net but my question is whether .Net makes some overloads in my huge matrix operation and other math functions?

If that is true, can I conclude that c++ is faster and better for these case of applications?
Updated 30-Apr-11 4:12am

If that is true, can I conclude that c++ is faster and better for these case of applications?

No, conclusions of this kind are, in general, not possible. You must be aware that there is some overhead in executing managed code compared to native code but in the end, both end up beeing compiled into platform's binary code. Given that both (native and managed) programs are equivalent in their run-time complexity it is not possible to say which one will run faster without "getting the stopwatch and some numbers" as OriginalGriff suggested...


A.Najafi 30-Apr-11 5:22am
Thank you very much for the time spending for me
Sergey Alexandrovich Kryukov 30-Apr-11 22:06pm
Like it, a 5.
If C++ your code is using .NET framework/compiler/CLI than it would be slower than native C++.
For example, and int is actually Int32, which is derived from System.Object and has some attributes inherited. It would have runtime penalty (exceptions etc).
Whereas a native int would just be 32-bit number, and nothing else attached to it.

An assignment which is higher than int's range would cause an exception for Int32, but would just overflow/underflow for native int.
A.Najafi 30-Apr-11 5:28am
Thank you very much for the time spending for me
When it comes to speed its the processor which processes the native code so the native code produced with C++ native dll and dll should be identical.

The .net framework keeps JIT to prepare native code from IL code and JIT is asked to prepare only if some method is being invoked very first time during the execution process. It may take some time over executing native code directly. but the alternate is creating a native image with ngen.

so once the code is ready in Navite image there will be hardly any performance hit as OriginalGriff also said.

If calling a native dll in .net code causes Marshalling then it's an overhead too.

To speed-up the process you can take benefit of multi-core processors.

A.Najafi 30-Apr-11 5:29am
Thank you very much for the time spending for me
Paul Michalik 30-Apr-11 5:29am
Well, the point is that given logically identical high-level code, the native assembly code generated by a "native" compiler can and usually will be different from the code generated by JIT compiler. In many cases the latter has a bigger chance to be optimized better and thus could run faster...
Niklas L 1-May-11 11:20am
Quite right in theory. Most notably cross module optimizations and use of target instruction set. I don't know how much of this is actually implemented in the JIT compiler though.
In general, VC++ .NET is a confusing name. In fact they don't call it that any more for this reason. It's just VC++ 2010 now. Writing pure native C++ would be your fastest option. That said, the performance difference between native and managed code is often irrelevant because JITed code runs natively. So it's not just a black and white situation here, and there are many factors that affect speed. An efficiently written mixed mode app that uses C++/CLI to mix managed and native code may actually be faster than a less efficiently written pure native C++ library (that does the equivalent). So these are factors you need to consider and eventually you may need to do some trial and error to hit upon just that right combination of managed and native code.
A.Najafi 30-Apr-11 11:01am
Thanks Again.
Nish Nishant 30-Apr-11 11:03am
No problem.
Sergey Alexandrovich Kryukov 30-Apr-11 22:05pm
Well-weighted judgment, my 5.
Probably, the fastest way to do it is to do your time critical stuff in a C++ native DLL (rather than a C++.NET DLL) and call that from your VB.NET or C++.NET software. Switching to C++.NET will probably have little or no effect on the execution speed.

Try it and see: Use the Stopwatch class and get some numbers!
A.Najafi 30-Apr-11 4:22am
Thank you very much.
CPallini 30-Apr-11 10:38am
My 5. However 'switching to C++.NET' is rather vague: with C++/CLI you may use native types as far as I know (and then you may use native types for the critical computation part).
OriginalGriff 30-Apr-11 10:42am
Sorry if it seemed vague, I was comparing it with his VB.NET software rather than with native C++.
CPallini 30-Apr-11 10:45am
So I was doing. I suppose C++/CLI might be faster than VB.NET since you may use 'raw' C++ for the hardcore calculations.
Sergey Alexandrovich Kryukov 30-Apr-11 22:06pm
Quite practical, a 5.
Stefan_Lang 2-May-11 9:42am
Is there an actual difference between using native C++ and VC++.NET as long as you're not actually using the managed types? Wouldn't it just work to use native types in time-critical parts and restrict use of managed types to the remaining, non-critical parts? Or does the mere gravitational pressure of the .NET library somehow influence performance, maybe through relativistic effects? ;)
Its clear that C++ is fastest then V-C++. Of-course if something is managed by CLR/.Net Framework then, it must be costing something. What it costs it speed... but what is the gain... gain is code reusability... portability... better error handling... all that worths a lot.
Stefan_Lang 2-May-11 9:35am
Actually you'd lose portability, not gain it. And I'm not at all sure why you think .NET code is more reusable than native C++. If you are using a framework, you restrict reusability to applications that use the same framework.
Bharat Kumar Arya 2-May-11 13:45pm
portability such as in JAVA... using JVM... CLR is also on the same line...
resusability is such though we have to use same framework but isn't the framework contains all you need if not it gives you flexibility to integrate it somehow...

no need to write from the scrap...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900