Just another trading platform - But this time different!

Quote from Swarm:

It can but it is excrutiatingly slow. When I backtested my forex strategy on OpenQuant it took 40 seconds against 10 years of hourly data (~ 60,000 bars).

My C code, can do 300 backtests per second with the same strategy and data. Must be another example how C# and .net is faster than native C code on a Windows platform (not).

Have a look at the great computer language shootout :-

http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php

C# comes in substantially slower than C, Java and even Haskell.

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.
 
Quote from LeeD:

...If we implement all computationally, intensive parts in C++ then what will be left to .NET is what .NET is best at: creating graphic interface. But then .NET GUI objects can be used from C++/CLI with minimal understanding of .NET and there is no need for C#.

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

Quote from fullautotrading:

My personal feeling about c/c++ has always been, when i coded in assembly (some ages ago), that for some projects i had much more power and <b>ease</b> just writing in assembly (especially having developed libraries and structures). On the other end, it did not seem enough "high level" or "friendly" when one really needed to attack the real large and complex projects (for instance create a ROLAP doing slice & dice on multidimensional cubes extracted from any DBMS, etc...), where the difficulties are more of conceptual nature. But that may be just a personal feeling ...
Tom, here you are addressing the real issue. "The best" language is usually the one the programmer is most familiar with.

Quote from NetTecture:

No, I am suggesting not focusing on an irrelevant small micro benchmark. It is a known fact that t.e C# runtime is not super optimizing tight loops, and this is what the so called benchmark had. I suggested putting MORE into the loop so that the overhead of the loop is less prevailing.
Espeically C++ compilers are wll knwn to optimize tight loop conditions. Without comparing the generated assemblert it is not even really possible to know what WAS executed on the C++ side.
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.
 
Quote from Steven.Davis:

I have looked at using gcc under Windows instead, but it is just so POSIX connected and I really like the Visual Studio IDE.
Out of curiosity, what was the motivation to use gcc?
 
Quote from NetTecture:
Espeically C++ compilers are wlel knwn to optimize tight loop conditions.


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

Without comparing the generated assemblert it is not even really possible to know what WAS executed on the C++ side. [/B]

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.

LeeD
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.

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:

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.

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~
 
Quote from LeeD:

Out of curiosity, what was the motivation to use gcc?

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.
 
Quote from Steven.Davis:

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.
 
Quote from mhtrader:

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.
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!

Quote from mhtrader:

Another of your smears:
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.
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.
In the opening post of this thread you wrote:
Quote from mhtrader:

-User written programs are not script languages. They are COMPILED for the CPU where it is running. No Java and No .NET, this is the real deal!!
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.
 
Quote from LeeD:

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!

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.
 
Quote from Steven.Davis:

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.
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?
 
Back
Top