Quote from dcraig:
Interesting. A couple of questions:
1. Why C++. It's always going to be more work writing in C++ than say Java or C# and will take longer to shake down the code. I really don't think performance is an issue. A lot is made of "real time" and the garbage collection issue, but IMHO it is rather overblown especially considering these things aren't running on "hard real time" operating systems anyway and the world it interfaces to is anything but "hard real time".
2. Why not use MySQL for the database ? Free, fast, stable and a little bit of SQL puts things in and gets things out. I know RDBs are probably not the best thing for time series, but in the interest of getting things done and concerning oneself with more pressing issues, it's not a bad choice. I log tick data from IB for about 50 stocks, most of the major stock index futures, and the Level 2 for 3 stock index futures into MySQL database on Linux box using Java/JDBC. It's really simple minded code - no FIFOs for buffering - and works fine. On an old Socket A Athlon 2800 CPU utilization is a few percent. Database is not on the root disk and uses the XFS filesystem.
3. How computationally intensive is this alpha blending stuff ? I know in Java it is significant, though may be better in 1.6.
A further comment on the API. Compelling the user of the Genesis API to incorporate a GUI into their application is just wrong and plain stupid. When will these people learn.
First, let me point out that C++ is not the end-all, be-all of my trading framework. C++ makes it especially easy to write COM/DCOM objects, so wiring my software for distributed use, free-threading models, and connecting it to C# and .NET can be especially easy.
I don't think C++ takes a lot longer to shakedown the code. I view the primary benefit of C#/Java as garbage collection, but using boost::shared_ptr<> and std::auto_ptr<> make my life reasonably simple. A lot of C++ programmers don't make effective use of smart pointers so memory management becomes a head-ache. Using boost::shared_ptr<> in cases where heap memory allocated objects are passed around removes some of the complexity, because a destructor will get invoked at some point when a copy of the shared_ptr<> no longer exists.
Without auto_ptr<> and shared_ptr<>, I imagine my life would be much more difficult. Exceptions would not have made things easier. However, smart pointers, in my opinion, take more of the hassle out of the mix.
Java and C# come with great class libraries. However, in addition to auto_ptr and shared_ptr, I have the STL. The STL provides me with fantastic templatized code that can make use of custom allocators right off the bat. The flexibility of STL algorithms makes programming equally as easy as using a .NET class library. Furthermore, with ATL and WTL, I get the GUI functionality I need to round out the playing field. The Java/C# edges are largely diminished when I make effective use of template libraries.
Additionally, who's to say the C++ code will run on Windows in the future? Using C# would restrict me to one operating system (Mono is not a viable option yet.) Java requires that I have a VM, so if I do formulate a model that requires a real-time response and want to run it on QNX, what will I do?
There's more benefits, such as fast processing of market data using SSE2 compiler intrinsics, having Intel VTune, simpler debugging interfaces with WinDBG, as well as the option of taking my software into the kernel if performance is a requirement.
Ultimately, C++ gives me the most flexibility in terms of design and interfacing to other languages. It gives me the most flexibility in terms of designing for performance should the need for performance exist. Because it can work as a bridge language, once core trading components are developed I can develop everything else overtop of my framework.
2) For the database choice of SQL Server 2005, I like it because I can author extended stored procs in .NET languages. The other reason I like SQL Server 2005, and it's just a person reason, is because I am familiar with COM and ADO. In C++, using ADO, it isn't that much more difficult than using ADO.NET with C#. The fact that MS provides smart pointer wrappers around a lot of the components used to interact with ADO makes my life easier, and I like that.
The write queue + stored procs for the database were simple enough to write and are already completed. I think I could streamline the process a bit further, but the database is currently not a critical part of the trading system aside from serving as a reference for developing trading systems. I have yet to find an edge, and FrostEngine is ahead of me by a long shot.
SQL Server 2005 also has an intuitive graphical management interface that I like.
3) Alpha-Blending costs me very little. The Win32 API exports alpha blending functionality, and I think (but am not sure) the hardware handles alpha blending once the parameters are set for a window. In order to turn off and re-do alpha blending, you have to reset the state of the Window with regard to it being layered and alpha blended.
4) I agree with that API thing. I don't like that HWND requirement at all. But at the same time, I don't care to reimplement all of the functionality they're offering me. As far as I know, they aren't providing any details for their protocols. I know how a good bit of their protocol works from looking at the wire; however, I don't want to deviate from the API in the event of them making changes and me not knowing it.
I'm not worried about Genesis' software at the moment. Their framework is good enough to build the basics off of. If they start to fail me, my software is flexible enough to allow for other brokerage interfaces to be integrated in easily.
I'm tired, so if any flaws are in my arguments above, allow me the opportunity to clarify and defend later.