I have developed a gray box using ANVIL API. It is a mixture of C# / VC++. The main reason is that it is portable to any other trading platform other than ANVIL. The GUIS are mcuh quicker to develop in NET than VC++. The C# engine takes singal from C++ and run historical analysis on them. I ahve to say once the signal is in, .NET runs as quick as VC++ but you ahve to code C# with C++ in mind. Avoid as many value references as you can. You will still suffer managed-to-unmanaged latency but once is crossover it is fast. Now, if you are building a scalper mechanism, you need to develop it on the native langauge of you trading API for optimal perfomance. This way you do not deal with marsahlling latency. I am awating t palce the all environment in 64 bit. It will be much faster and much more capacity for our historical analysis.
Are you sure ? If a strategy relies on limit orders, for example, there will be interesting issues in automation that don't exist for one based on market orders. Stocks will have other issues than futures - order routing ? no stocks to short etc. High freqency will demand the best executions. I'll bet there is plently of scope for the order management code requirements to vary significantly depending on the type of strategy.
Well, you touch the point more accurately. I was trying to divide the code for strategy(rules) itself and the code for autotrading. Yes, autotrade codes for limit orders, market orders and stop orders,etc. are quite different. And the codes turns much longer if you decide to make dynamic modifications to the orders. But still there are only limited number of autotrading models to be integrated into ATS. Personally I save some autotrade templates in my computer so when I need to assemble a new ATS, I can conveniently make use of them. On the other hand, the number of the models of strategy(rules) is virtually unlimited. I guess we all have personal favourites.
It took considerably more effort to design and code than had I just reused code that I have that connects to datafeeds, does order management, etc. It took no more effort because I had the strategy running on older less well designed code while crafting the new code. It is when I had a eureka moment that I saw a unification of all my code. This came as I became a better programmer. Most programmers are content to stay where they are on the expertise scale. I am never satisfied with mine. I am constantly refactoring, looking for abstraction, looking for unification. But this requires experience and a language with a powerful grammar. I don't exclude one at the expense of the other. When my systems are running, I am either coding new abstractions, or I am researching new trading models. Often, the systems drive the code to the utmost abstraction as I realize the system can be traded on any market. nitro
The system is all ecompasing. It does many many things that are basic to all of trading. The one thing is weak in is actually trying to find systems using historical data. I am way past that sort of system. Inspite of that, I will be adding a module to do that sort of analysis, but it will be far more general than just testing a system against canned indicators. nitro
In all the tests I have run, I have found that even for the most demanding system that I could imagine, Visual C++.Net was equal to the task. The only reason that C# is not as fast as C++.Net is because the compiler is more mature. Otherwise the CLR is the same. What I do is use VC++.Net for the utmost speed, and C# for the rest (I actually use VB.Net as well.) There is no penalty for cross marshaling in that case. As for 64-bits, all of my software is compiled ANY CPU, so it runs correctly on any platform (although it is tricky to get it right in VC++.net) nitro
I no longer think around retail strategies. Dealing with limit orders etc was conquered long ago. I am now going after much bigger game. That requires direct connections and mass quoting APIs from the exchanges. It you aim for a million, it is easier to make $100k, and so on. nitro
another additional criterion in my case was to use a fairly terse language since i don't want to have to pour over hundreds or thousands of lines of code written by someone else i outsource parts to, where a couple dozen / hundreds suffice... not sure anything C is the best choice for that...
quick update - we've had to make 2 small but worthwhile enhancements to our auto-restart auto-reconcile logic, in order to handle various cases of Transaction Log lags at the broker's end... that's the only bit that's caused us problems so far, although not a daily occurrence
I don't like super terse languages (although to some, C is terse.) There is a famous story of, I think it is Bear Stearns, hired the inventor of APL. He developed a language that is very powerful (I forget the name) and his son ended up writting a large part of their software. Well, for every programmer that understands this language, there are ten thousand that understand C. It got to the point where no one knew how their models were implemented. C# has very powerful semantics. I am hopeful that the language continues to takes clues from other languages on their best features, and incorporates in a natural syntax the best of that research. So far, IMO MSFT has done a stellar job of including the best constructs from other languages into C#. nitro