Just another trading platform - But this time different!

With all due respect, from your previous post you come across as someone who has a strong motivation to create something, you also seem to know what you are talking about in terms of core programming skills. However, you sound miles off from understanding what any of your intended audience actually needs. I am myself not a developer (means coder) but I design, test and trade quantitative strategies for institutional desks for many years now. We run strategies that process ticks and market depth on thousands of symbols in many different markets. And let me surprise you: The engine is entirely written in C#. We utilize KDB for our data needs and all works seamlessly together. I dont want to get involved in coding details as I am not qualified to participate.

But I understand full well what we as quant traders and strategy developers need from a testing and quant trading platform environment. I need a base platform that is purely event driven. I need events that handle tick trades and market depth changes (equities). I need an environment that provides knowledge within symbol A instance of the states in symbol B or C. I need the ability to raise time based events (time aggregated bars) and tick aggregated bars. I need the ability to zoom through tick data at high speed that enables me to run back tests at reasonable speeds.
I need a platform that provides data structures that allow me to pull any kind of raw data to perform calculations, such as all ticks on the day, the days open tick, the last tick, the tick n lookbacks ago, the tick at or right after 11am every past n days,...

I dont need an environment to perform optimizations, I do so within other more efficient environments, such as matlab, splus/R. I need to be able to log whatever I like at any "node" in the strategy, whether raw data aggregation, signal modules, statistics, order creation, order management...Thats it, at least in terms of backtesting. Trading the strategy necessitates a full Order Management System, Position Management System, Transaction Cost Module, Risk Module, Fix Execution Engine, among others.

Having this I can write you any strategy under the sun and I have already done so, among others equity HFT strategies, fx trading strategies, several agency algos. All off the back of .Net/C#. I could not disagree with you more that any platform that forces you into any sort of symbolic language has an advantage over an environment where you are provided with some highly efficient basic structures and can develop all else on top of it. I agree with you, however, that none of the current off-the-shelf products solve even remotely the needs of a serious quant trader/desk. There is no way around a platform that is written from the ground up. Of course many commercial components can be used to avoid having to re-invent the wheel, such as KDB, TIBCO message bus, ...

Thats it. I dont mind the implementation details of the platform as long as above requirements are met. So I dont fully understand why you delve into discussing compiler pros and cons while you dont even listen to those who are supposed to use your future platform. I suspect you got your priorities a little messed up.

I suggest you start with the end user in mind, what is really needed as opposed to you showing off your coding skills because it wont get you very far, imho.

 

I don't disagree with you. But most of the people jumped here on the technical side of it with pseudo-science, talking-points, shallow analysis and esoterism. .NET is not good enough for engine/plumbing code and it can be good enough for UI/graphics. I'm an engineer and not a trader and most of the comments here are clear lies... and it looks to me that a lot of people take then as truth.... I couldn't let it like that. You can read my posts here thru the thread... on the technical posts I tried to put then with facts that can be checked an reproduced. If someone disagree.. it is not disagreeing with me... but with the facts.

I don't pretend to write any strategy for anyone. My only intention is to give you the best tools for your need, and basically the fastest tools you can have for the features you are asking... I worked for +8 in a platform that was probably the #1 or #2 platform in the market year after year... I spend "years" in meetings of all kind regarding the "unsolved issues"... All of these issues came from feature request from customers: institutional and retail traders. Interestingly they do different things but they want almost the same features. We/they studied the competition like crazy and the only thing that let them sleep at night was: "well, we can't do this... but for now no one can do it either, so we are ok", my non-compete expired a long time ago by the way... Sometimes companies can't simply say: I'm gonna re-write everything from scratch... sometimes they are carrying 10 or more years of legacy source code of C, C++, some .NET... too costly to rewrite. But we don't have that problem. We started from scratch.
And yes we have a strong motivation to do it

Thanks,
~mhtrader~

 

About your .Net dislike I can only comment that you do not seem to be too well connected on the institutional side. Most sell-side shops and hedge funds alike are all working hard to port their libraries from C++ to C#. There is a huge effort in the industry to get things running in pure .Net environments, not just on the front end side of things but even for core calculation engines. In thus, I dont think you are right with your comments on the usage of .Net limited to the UI side.

Additionally, I am not sure you gain much by calling others liars who seemingly made an effort to engage in technical arguments, to me a number of other participants in your thread sounded quite informed.

To me you sound like a lot of coders on the IT side of banks: They can argue for years about the beauty of algorithms and how to squeeze out the last bit of performance but they have a very shallow understanding of the tools a strategy developer and quant trader really needs. Maybe I judge you prematurely, just share my "hunch" from what I ready about your posts here. Do you have an understanding of the data structures we as traders really need? If yes then I recommend you distance yourself from getting into deep discussions of assembler and other in-depth implementation details because it just shows your focus is on the wrong side of things...

Happy Chinese New Year to everyone (at least those who celebrate it).

 

As we have now so many time repeated, there is something called <b>"progress"</b>. And .NET is certainly, beyond any doubt, a remarkable expression of it. Also made necessary by internet development.

If we lived for pure local performance, and did not care of all other aspects, like ease and time of development, maintenance, focus on conceptual aspects, high level optimizations, etc.,
we would all be programming directly the microprocessor.

Just looking at what is supposed to be a (monkey-proof) useless "optimization" we see that what it's just a trick to "anticipate" and evidently "cheat" on specific benchmarchs. Further, what, in assembly, any programmer would have done with a single line, has been done there with 3. That code is just horrific for an assembly programmer (but nevertheless we have no problem to accept it because it's an automated generation which saves us a lot of time, allowing to focus on ideas).

In some similar way, from a robot we accept redundant trades which might not be made by a discretionary trader, because the robot works with an automated logic, and makes money while we sleep or spend time with our women or children, and works on a large number of instruments simultaneously.

Anytime there is a progress, there are always people who have committed to much time learning earlier "masochistic" tools that they continue to feel hopelessly attached to them. I know people who would not give out the VI editor for anything in the world, even on a windows machine. It's usually useless to attempt to argue with people with this attitude, unless one takes it as an amusing entertainment.

After all it's good that there are different views, because the market needs both winners and losers.

Tom

 

At the risk of sounding like a newbie, what are the advantages of C# implementation over C++/CLI? The latter preserves C++ syntax but, I understand, produces a pure .NET implementation. Is the main reason that libraries in C++ don't use .NET containers such as arrays and strings?

 

Asiaprop may well have a better answer, but I think that it is a valid question of which I have some experience.

C++/CLI is really cool, but it is a migration step between C++ and C#. Certain things, like having your whole C++/CLI assembly depend on a whole C# assembly rather trying to map class/file dependencies is a real drag to continued C++/CLI development.

C++/CLI development is even more clunky than either C++ and C#. For example, suppose that you want to provide a CLR wrapper a numerical algorithm that operates on an array:

Code:

using namespace System;
#define SIZE 10

#pragma unmanaged
// native function that initializes an array
void native_function(int* p) {
   for(int i = 0 ; i < 100 ; i++)
    p[i] = 10.0*sin(i*2*3.14/100);
}
#pragma managed

public ref class A {
private:
   array<int>^ arr;   // CLR integer array

public:
   A() {
      arr = gcnew array<int>(SIZE);
   }

  int DoIt() {
   pin_ptr<int> p = &arr[0];   // pin pointer to first element in arr
   int* np = p;   // pointer to the first element in arr
   native_function(np);   // pass pointer to native function
   return sum();
   }

   int sum() {
      int total = 0;
      for (int i = 0 ; i < SIZE ; i++)
         total += arr[i];
      return total;
   }
};

native_function now does its job in hopefully, regular C++ speed, but the pin_ptr is getting in the way of garbage collection. When it is done, then you release the pin and are back to managed redirection. Now I must remember that it is 'arr', not 'p', not 'np'.

Even if not, I would think that the experiences of going from COBOL/FORTRAN to C to C++ has taught large companies that it is better to pull-the-bandaid and keep development to one framework at a time.

I am grateful that Microsoft created .Net with C++ support, and that the Mono group has made .Net more broadly available.

 

Again, I am not a programmer so I cant go into specifics of language differences. But I think that was my very point: The language specifics is not the important point. I understand that an excellent C++ coder can write slightly more efficient/faster code than a good C# coder. However, I believe the whole .Net environment provides a platform that allows whole teams to bring to market a complete system architecture in a lot shorter time than something that is entirely written in C++. Think of addressing issues of connectivity to high efficiency data bases such as KDB, new messaging buses, fast porting of development environment strategies to production, UAT processes,... Think also about how the code is actually being used. In most sell side firms its gonna be libraries that allow traders to access pricers within Excel or other lightweight GUIs. Ask any GUI developer and they will tell you it takes 1/10 of the time to get charts and other graphical elements implemented as part of newer C# supported 3rd party libraries than going through C++.

I as strategy developer and trader appreciate C# because, for instance, a lot of dictionary and list classes are already provided out of box without me having to search for libraries elsewhere or write code myself. I dont need to care about garbage collection, many coding specifics that had to be specifically implemented in C++ are already taken care of in C#. Laugh at me but I have not had to deal a single time with pointers when writing strategy back tests in C#.
I care most about being able to write routines on the fly in order to test ideas.

Apologies that my answer wont satisfy language fetishists and other detail enthusiasts, I focus on getting stuff tested and to market quickly to make money, I am not being paid to write elegant or beautiful code (that is the job of my programmers who port the strategy into production). In order to minimize strategy/implementation risk it wont make any sense at all to test and write algorithms in one language and then implement in another language.

 

The thing that I liked about using MatLab is that there was little enough distraction from the Mathematics that I could hold a line of reasoning. C# is alot closer to C++, but the more the author can keep focused on the feature, the more productive. Short of enterprise-wide platforms, optimization can come later once the ideas are proven.

 

As you said: YOUR BELIEVE. This is not a fact.

This is a "weak" argument... asking VB.NET programmers compare to C# programmers... may yeild similar result. And by the way the people that will answer like that they know C#, but may not know C++.

Never ever .NET will have the variety of containers you have in C++ and all of them compile-timed resovled and not like .NET generic that are a runtime-based variation of the C++ Templates. C++ container speed will never be matched. I have .NET source code in my hand here and boost and STL.. So I can tell you with absolute assurance. Reference: http://boost.org and STL. Most of the libraries there are part of the C++ Standard Libraries. For more information look at the post where I mentioned what happens when you touch the length property in an Array: myArray.length is a function call into a CLR DLL written in C++ with more than 20 lines( and there you have more function calls ).

There is no garbage collection in C++. I don't know what are you taking about. Having the CG makes your life more miserable if you need performance. The GC is there you like it or not.. running in other threads... locking you when you don't ask for. Making massive memory copies ( the slowest point, bottleneck of most programs written in any language ).

I don't know on what stage/year you left C++, but unless these are talking points, you don't need to deal with pointer in C++ and you don't need to deal with the delete keyword in C++. The STL alone allows you to write code in way that you don't need to deal with any of these things. Most moderm C++ programs are written like that. Since most people may thing like you about pointers and C++, I encourage them to read more, because that belongs to the Jurasic age of C++. On top of that, I'm pretty sure you may not know what this means... but it is worst for you to research it: C++ destruction is deterministic, you don't have that in .NET. You can find this subjects in the discussion groups of Microsoft Engineer that participated in the .NET design and the CG design. Just because of that simple problem they were force to add the Dispose method... that .NET developers are responsible to call. You don't have that problem in C++. So in that sence C++ is more simplified that C#.

Clearly you don't care about performance.


Thanks,
~mhtrader~

 

We do care about "performances". We just have a different way to measure them ;-)

Our way is <b>$/risk</b>

Show us some results, and you can be more effective in making your points. Here the focus is on money making, not on meaningless language wars.

Your users could not care less of the technology you used. What counts is how much money they can make with it. And an eccessive focus on technology may rise legit suspects in potential users, which you, sooner or later, will need to clarify.

Tom