That chart comparison is using C# under Mono, not native .Net. Native C# under .Net has better performance numbers than running the same c# code under Mono. Not a fair comparison. http://bytes.com/topic/net/answers/629771-net-vs-mono-performance Your link is also for comparison language on Ubuntu, not Windows. No one is going to argue that C is not the best implementation whether using Windows or Linux, but C# in .Net is not as bad as most want to believe.
That is exactly what I have done. I use C++/CLI for calculation and C# for display. Everytime, I add a reference to the .Net assemblies in my C++/CLI code, I see a performance hit. Then I go looking for an STL equivalent, if none, roll-my-own. To keep the C# clean, there is a C# assembly with some base classes called by the C++/CLI computation assembly called by a C# assembly to do the display. It is just unfortunate that when something changes in the base class assembly, the whole C++/CLI assembly must be rebuilt. I should be thankful that it works as well as it does. I have looked at using gcc under Windows instead, but it is just so POSIX connected and I really like the Visual Studio IDE.
Haha! Thanks for the fun link Tom, here you are addressing the real issue. "The best" language is usually the one the programmer is most familiar with. Hi NetTecture, my post you quoted was actually addressing specific points Fundjunkie made. Funny enough, the discussion I linked earlier http://www.daniweb.com/forums/thread155136.html demonstrates that with a simple example like in the "benchmark" in question C++ compilers are capable of optimising the whole loop away (repeated summation would be replaced with a single multiplication). Clearly, this is not going to happen with loops that produce less obvious result. Anyway, as you may have noticed I have been trying to stay neutral in the main argument regarding whether code in C++ runs necessarily faster than the same algorithm implemented in C#. I believe for most applications any realised difference in performance is irrelevant. Even more so if it comes at the cost of lost programmer's productivity. However, observe how adamantly Mhtrader is defending the point that not letting users implement trading strategies in their favourite C# is a major selling point of his platform. I find watching it rather enjoyable and would hate to break his groove.
This is mental gymnastics... global warming. Can you SHOW THE PROOF with that example i posted? You can't... because in that case there is no "loop condition optimization" <= another esoteric phrase Welcome to the jungle. There is not such loop optimization in the loops. C++ generated code: PHP: 00B01003 83 EC 08 sub esp,8 00B01006 53 push ebx int x = 0; unsigned int uTicks = timeGetTime(); 00B01007 8B 1D E8 20 B0 00 mov ebx,dword ptr ds:[00B020E8h] 00B0100D 56 push esi 00B0100E FF D3 call ebx for( int i=0;i< 30000000; i++) 00B01010 8B F7 mov esi,edi 00B01012 89 45 FC mov dword ptr [ebp-4],eax 00B01015 69 F6 80 C3 C9 01 imul esi,esi,1C9C380h { x = x + param1; } for( int i=0;i< 30000000; i++) 00B0101B B8 80 C3 C9 01 mov eax,1C9C380h { x = x - param1; 00B01020 2B F7 sub esi,edi 00B01022 48 dec eax 00B01023 75 FB jne 00B01020 } unsigned int uTimePassed = timeGetTime() - uTicks; 00B01025 FF D3 call ebx 00B01027 2B 45 FC sub eax,dword ptr [ebp-4] std::cout << "Milliseconds: " << uTimePassed << "\n"; 00B0102A 68 34 21 B0 00 push 0B02134h 00B0102F 50 push eax 00B01030 A1 7C 20 B0 00 mov eax,dword ptr ds:[00B0207Ch] 00B01035 68 38 21 B0 00 push 0B02138h 00B0103A 50 push eax 00B0103B E8 90 00 00 00 call 00B010D0 00B01040 83 C4 08 add esp,8 00B01043 8B C8 mov ecx,eax 00B01045 FF 15 6C 20 B0 00 call dword ptr ds:[00B0206Ch] 00B0104B 50 push eax 00B0104C E8 7F 00 00 00 call 00B010D0 00B01051 83 C4 08 add esp,8 return x; 00B01054 8B C6 mov eax,esi } Again SHOW a real proof of what you said. Show code and examples. Back your comments. Hey LeeD, I don't know who wrote that forum post, but it looks to me it was a LAWYER???... SO you are using a lawyer's post to show this?? OMG! The information in the post is wrong or misleading at best! In your link the person posted the non-optimized version of the function because he couldn't find the function in release, it is optimized away do to the use of constants and function inlining. The C++ function in that post is way slower than the ASM function. I copied and pasted the function from your link and here is the real optimized function, the one that is faster, and I invite you and other to click on your link and check it and compare the actual code of the C++ function. My C++ compiler( that is not the best in the market) generates this 6 instructions: PHP: char cppToUpper(char c) { if (c > 122 || c < 97 ) 01081000 8D 48 9F lea ecx,[eax-61h] 01081003 80 F9 19 cmp cl,19h 01081006 77 06 ja 0108100E return c; else return c - 32; 01081008 0F BE C0 movsx eax,al 0108100B 83 E8 20 sub eax,20h } 0108100E C3 ret LeeD next time try to fact-check before you post or you may be spreading a lie again. Another of your smears: I have never mention what language the end user will use to write the strategies. I invite you to go thru the 12 pages to find that... you are not been noble. Thanks, ~mhtraders~
I have an econometric C library that I have not been able to port to C++/CLR. If I could pack it in a DLL, then I could use it. My old favorite Borland C++ Builder 6 doesn't work under Windows 7, and besides, I remember gcc doing a good job performance-wise.
The package is libgretl for cointegration. I spent over 10 hours trying to get C code written for one compiler to work as extern "C" within C++/CLR. Then I spent another half day trying to get various gcc base packages such as Eclipse going. In the end, a poster suggested connecting to a statistics package using OLE which works albeit slowly. Many thanks to those who were concerned.
Hi Mhtrader, I admit I didn't read the post I linked with prejudice. But I see neither did you read it very thoroughly. The OP in http://www.daniweb.com/forums/thread155136.html tests C++ code against his own assembly code "inlined" in a C++ function and the same assembly code compiled as a separate (pure assembler) module. What he finds is inline assembler is substantially faster than assembler in a separate module (though it is the same code) and pure C++ takes zero execution time no matter what. In fact, in my tests the C++ code compiles into: Code: ; 78 : { ; 79 : stopwatch watch; 00024 ff d7 call edi 00026 89 44 24 14 mov DWORD PTR _watch$77957[esp+24], eax ; 80 : for (int i=0; i < 10000000; i++) ; 81 : { ; 82 : ; 83 : // cout << cppToUpper(c); ; 84 : //cout << cppToUpper(d); ; 85 : e= cppToUpper(c); ; 86 : e= cppToUpper(d); ; 87 : } ; 88 : ; 89 : } 0002a 8d 44 24 14 lea eax, DWORD PTR _watch$77957[esp+24] 0002e 50 push eax 0002f e8 00 00 00 00 call ??1stopwatch@@QAE@XZ ; stopwatch::~stopwatch ; 90 : cout << "That was C++\n"; 00034 8b 0d 00 00 00 00 mov ecx, DWORD PTR __imp_?cout@std@@3V?$basic_ostream@DU?$char_traits@D@std@@@1@A 0003a 68 00 00 00 00 push OFFSET $SG-103 0003f 51 push ecx 00040 e8 00 00 00 00 call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z ; std::operator<<<std::char_traits<char> > As you can see the cycle is gone. This perfectly illustrates my earlier point that C++ compilers are capable of optimising away whole cycles. I don't know what that long "disassembled" code refers to. It wasn't the reason I posted the link. I think it was quite clear from the post I linked that the poster himself was confused about the role of this code snippet and felt something was out of place. Mhtrader, in conclusion, you are nitpicking. For the sake of other readers, there was indeed a statement in my post which was incorrect. By an optimising C++ compiler "repeated summation would be replaced with a single multiplication". I tested this on 2 compilers I routinely use and neither of them does this kind of optimisation. My bad! In the opening post of this thread you wrote: How else can I interpret this other than: 1) You platform doesn't support trading strategies in C# ("No Java and No .NET") 2) It is a major selling point ("this is the real deal!!") BTW, from your confrontational tone I detect you interpreted my post as a personal attack. I believe it was quite constructive but if you found it offensive I apologise. It wasn't my intent.
I was surprised that you thought that compile-time optimizers were smart enough to convert loops into multiplication. I once worked with a guy who had worked for Cray. The team he worked in was dedicated to tweaking the C and FORTRAN compilers to get the best benchmark numbers possible. Since these were heavily numeric benchmarks, that is exactly the kind of thing that they spent their time building into the optimizer. Maybe someday this will be mainstream. I was surprised by my original benchmark post in this thread that the .Net 1.1 was outperforming the .Net 2.0. Since 3.0 and 3.5 use the same CLR, they should have the same performance. The new .Net 4.0, though, I think uses a new CLR. According to http://stackoverflow.com/questions/2864223/are-net-4-0-runtime-slower-than-net-2-0-runtime Code: * VS2008 o Target Framework 2.0: ~0.25 seconds o Target Framework 3.0: ~0.25 seconds o Target Framework 3.5: ~0.25 seconds * VS2010 o Target Framework 2.0: ~3.8 seconds o Target Framework 3.0: ~3.8 seconds o Target Framework 3.5: ~1.51 seconds o Target Framework 3.5 Client Profile: ~3.8 seconds o Target Framework 4.0: ~1.01 seconds o Target Framework 4.0 Client Profile: ~1.01 seconds It has certainly been my experience that my code with debugger attached runs terribly slow since switching from VS2010 to VS2008.
I understand you solved the problem. So, it's not a pressing issue. In case it helps... I'm sure you know that in Visual Studio 2005 and higher a C++ project has compilation options on the per-file basis. Each file can be compiled as C++, C++/CLI, or C. Then the linker makes sure all of these 3 types work together. Have you tried if the libgretl compiles as C?