Just another trading platform - But this time different!

[mhtrader]

Hey NetTecture,

Don't take this so personal... Can you explain why this bother you so much? Is it affecting your business?

You have to ACCEPT THE FACTS. Based on your reasoning... if you put more code inside the loop somehow a magic will make C# faster.... are you serious?

Let's see how many people you can convince with that.

If you have something better to say other than ranting.. for example some benchmark... please do it with facts and SHOW THE PROOF as I did: source code, data, etc.

Thanks,
~mhtrader~

PS: You make me feel like Mcintyre against the climate-gate pseudo scientific community.

Quote from NetTecture:

Welcome to the world of fools makin tests that are irrelevant. You did not have to downgrade the C++ compiler - most are smart enough to realize how useless your code is and pretty much totally throw out the loop.

The test pretty much says a nearly empty loop is sloer in C#. Gratulations. Now, we knwo the C# compiler is really not optimized for micro optimizations.

That said, your strategy is cool. Does nothing. Try putting some real code in there.

 

[NetTecture]

Quote from mhtrader:

Hey NetTecture,

Don't take this so personal... Can you explain why this bother you so much? Is it affecting your business?

You have to ACCEPT THE FACTS. Based on your reasoning... if you put more code inside the loop somehow a magic will make C# faster.... are you serious?

Let's see how many people you can convince with that.

If you have something better to say other than ranting.. for example some benchmark... please do it with facts and SHOW THE PROOF as I did: source code, data, etc.

Thanks,
~mhtrader~

PS: You make me feel like Mcintyre against the climate-gate pseudo scientific community.

The fact?

C# is slower in useless microtests.

Gratulations.

Now put in some real methods that actually spend MORE time in the method than in the loop and see what happens next.

 

[fullautotrading]

Quote from NetTecture:

The fact?

C# is slower in useless microtests.

Gratulations.

Now put in some real methods that actually spend MORE time in the method than in the loop and see what happens next.

well, if he uses assembly will be even faster

 

[LeeD]

Quote from fullautotrading:

well, if he uses assembly will be even faster

This is a common misconception.

To write a fast code in assembly language requires deep understanding of how modern processors work. Also if you make suboptimal choice at any point, C++ compiler will ususally fix it for you. In assembly language you will be just stuck with a slower code.

Search google for "assembler versus c++" (without quotes). You will see lots of people are being surprised how much faster the C++ code compiled by an optimising compiler compared to Assebler code they would write.

From http://www.daniweb.com/forums/thread155136.html:

Why is the C++ code considerably faster even though it compiles to far more instructions than my assembly language code uses? 48 "ticks" expire when executing the pure assembly language function 10,000,000 times (I'll put this stuff at the very bottom); 0 ticks when executing it in C++, and 16 when using inline assembly?

Further, you can speed up actuall C++ code a lot via simple "tricks" like avoiding excessive branching within a loop and declaring everything you can as "const".

Then, if you do understand how processors work, there are lots of things you can speed up in C++ without resorting to assembly language. For example, copying a long string byte by byte is the "natural" way to do it. If instead you copy (most of) the string as 64-bit integers aligned to addresses divisible by 8, you may see near 10 times improvement. This is the kind of optimisation the optimising compiler or NET JIT wouldn't do for you because the basic assumption is most strings are short and on very short strings this approach may result in a substantial hit to the performance. Only you as a programmer know that most copied strings will be long.

 

[fullautotrading]

Quote from LeeD:

This is a common misconception.

To write a fast code in assembly language requires deep understanding of how modern processors work. Also if you make suboptimal choice at any point, C++ compiler will ususally fix it for you. In assembly language you will be just stuck with a slower code.

Hi LeeD. Have you noted the sarcastic icon ?

I have been coding in assembly (in the past) for at least 6 years.

There are unique advantages to using higher level languages, when one does large and complex projects. And that is the reason why we are not coding in assembly.

What people are trying to say here is that is meaningless trying to make a point with a couple of loops. It may only denote scarce familiarity with real complex projects.

Creating profitable automated trading systems is all another matter.

Tom ;-)

 

[LeeD]

Hi Tom

Quote from fullautotrading:

Hi LeeD. Have you noted the sarcastic icon ?

I haven't used "smilies" often enough to know :p means "sarcasm". I guess this is one more topic for me to catch up with...

Given I have seen similar sentiment regarding the assemply language from other posters in this thread, I thought providing somewhat comprehensive a comment wouldn't be a total waste of time

 

[fullautotrading]

Quote from LeeD:

Hi Tom
I haven't used "smilies" often enough to know :p means "sarcasm". I guess this is one more topic for me to catch up with...

Given I have seen similar sentiment regarding the assemply language from other posters in this thread, I thought providing somewhat comprehensive a comment wouldn't be a total waste of time

ahah cf:
http://www.elitetrader.com/vb/showthread.php?threadid=214288&perpage=6&pagenumber=2

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

 

[fundjunkie]

Quote from mhtrader:


Here is the output. The test was repeated several( 20 or 30 times ) times under same conditions and always produced similar results:

As far as I'm aware, it's a well established fact that C# iteration is much slower than C++. So, can't the iterative elements of the code be externalized to C++ dll(s)? And would that not marginalize the point behind this benchmark to the point of it being meaningless?

I do respect the technical choices you've made and the reasoning behind them. But seeing as I'm pondering doing the above myself I thought I'd throw that out there. My assumption is that static C# code combined with an external C++ "iteration manager" should offer significant performance gains while retaining the advantages C# and .Net offer.


Thx
D

 

[LeeD]

Quote from fundjunkie:

As far as I'm aware, it's a well established fact that C# iteration is much slower than C++. So, can't the iterative elements of the code be externalized to C++ dll(s)? And would that not marginalize the point behind this benchmark to the point of it being meaningless?

I do respect the technical choices you've made and the reasoning behind them. But seeing as I'm pondering doing the above myself I thought I'd throw that out there. My assumption is that static C# code combined with an external C++ "iteration manager" should offer significant performance gains while retaining the advantages C# and .Net offer.


Thx
D

Are you suggesting to implement the actual loop in C++ and call C# code on each iteration? Corossing native/.NET border (such as calling a .NET subrutine from C++ or vice versa) is an "expensive" operation in itself and will likely make the code slower if anything.

If you are suggesting to implement all the code within the loop in C++, then it defeats the purpose of using .NET. You still have to know C++ (and know it well). The data structures used within the loop should be in C++; so, we loose the advantage of garbage collection.

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

 

[NetTecture]

Quote from LeeD:

Are you suggesting to implement the actual loop in C++ and call C# code on each iteration? Corossing native/.NET border (such as calling a .NET subrutine from C++ or vice versa) is an "expensive" operation in itself and will likely make the code slower if anything.

If you are suggesting to implement all the code within the loop in C++, then it defeats the purpose of using .NET. You still have to know C++ (and know it well). The data structures used within the loop should be in C++; so, we loose the advantage of garbage collection.

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

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