I need to write software that will do a lot of math. Mostly it will be matrix multiplication with integers to compute DCT. How much faster should I expect the code to run in native c as compared to VB .Net? Factor of 2, factor of 10, factor of 1000...? Has someone tried and collected statistics on this?
A:
The .NET code is compiled into native code by the JIT compiler, so you get native code in both cases.
The difference is that the C code has somewhat less overhead around the calculations, so you should perhaps expect a performace difference of factor 2.
Guffa
2010-03-04 13:39:53
"overhead around the calculations" - what overhead are you talking about? .net code that manipulates with basic data structures as integers is compiled to very efficient form
Andrey
2010-03-04 13:44:24
@Andrey, I think Integer overflow checks are just one example.
M.A. Hanin
2010-03-04 13:54:05
@Andrey: VB does some extra work here and there, like for example initializing all local variables to zero. Then there is some overhead that comes with the managed way of doing things, for example range checking of the index when you read an integer from an array. In .NET it's not possible to read outside the array, while C will blindly hand you whatever you point at.
Guffa
2010-03-04 13:54:09
yes you are right, but when you program in C you should also check array bounds, but you implement it yourself. about overflow checks use unchecked. again, in C you should also check overflows
Andrey
2010-03-04 13:58:20
A:
.Net code is JIT-compiled to native code before execution, so it should not be slower than native code in general. I'd expect a factor < 10.
Moreover, adaptive optimization techniques profile the code as it runs, gaining more information than a typical static compiler. So, the JIT can make more informed decisions for further optimizations
ahmadabdolkader
2010-03-04 13:41:46
The debugger can help with that. Not sure about JIT, but I guess it wouldn't be much different than this: http://www.programmingforums.org/post166503.html
ahmadabdolkader
2010-03-04 20:16:53
A:
VB is 93.7% as fast as C. If you pick the right scenario.
Actually, if your 'native C' includes regular calls to malloc() and free(), any kind of Gargage Collected language like VB.Net is going to literally run circles around it. GC can be 10x faster than mallocs in your inner loops.
If you break down and use C, try to reuse structures that you declared just once instead of making new ones, to avoid this problem. This may be of benefit even in VB if your solution lends itself to it. However it will be harder to program and GC is very fast.
As far as bounds/overflow checks, if speed is important and testing has revealed they don't happen, and you're not risking life or millions from an error or abend, they are a waste of time. But if you can't get rid of them, your time is likely still more valuable in a language with which you can program more quickly.
If you expect serious size and usage, it pays to split the task with a controlling program and store the allocated 'task definitions' into a shared directory with a file per task solver, or a database. Then you can run a solver per processor (2 per HT CPU), or network computers. Be weary of queue structures - it's tough to atomicly 'Mark-Taken-And-Get-Data-If-Not-Taken'. You know how many task solvers you're going to start. I did this with an imaging utility I develop, it was much easier than expected, and it creamed the previous version. Plus if you use multiple processes with a properly dividable problem domain, you avoid the slight-to-significant programming burden of multithreading. Or convincing your coworkers that your culrly braces are in the right place. Peace.
FastAl
2010-03-05 21:08:02
What does "VB is 93.7% as fast as C" mean? 93.7%, where did you get that number?
AMissico
2010-03-10 23:34:50
"bounds/overflow checks", reader, note that you can turn off VB.NET's integer overflow checks, which gives VB.NET the same performance as C#.
AMissico
2010-03-10 23:35:18
How does one type of code LITERALLY run circles around another? I'd love to watch that.
Dinah
2010-03-10 23:50:48
@Whoever DV'd me - see the last word in Q#3 of the S.O. FAQ! and RESPECT THE GARBAGE COLLECTING MEMORY ALLOCATOR. You will not believe the difference in speed that it makes for everday code. Do some googling if you don't believe me and don't have time to try a solution in both types.
FastAl
2010-03-13 03:42:18