How to build an automated system

Quote from hft_boy:

Oh, I forgot to answer this. Nothing is *wrong* with C++ per se. It is just hard to write, hard to read, hard to maintain, and generally messy/ugly. Especially -- who the f*** came up with templated code? It kind of makes sense, but is impossible to work with. FWIW my C++ is basically C with some classes for reusable code and the occasional std::vector. Even std::string makes me shudder :P. I think it is just std::vector<char>. Like, seriously? Is that really necessary?
More...

What is wrong is that there is not a single C++ compiler on this world that implements the whole langauge spec - it is that complex to do (there is anarcane feature in templates missing in every one, status is it is thought impossible to implement). Even the designer who did C## has said in an interview he would do things different a second time - very different.
 
Quote from hft_boy:

Jebus I didn't actually expect so many responses.

@clearinghouse: Provider. And don't have access to serious speed although I wish I did ;).
More...

How do you provide liquidity without speed, or are you willing to accept "blow throughs" to open a position? I.e., you're spreading, but entering in with a passive leg -- and the spread is more or less where your profit comes from?

My homebrew system has a wire latency of around 2-3ms, which is total crap in today's market. I put a passive order and it's a guaranteed blow-through about 85% of the time. The only solution is break-neck speed, but it's hard to come by. The system favors the entrenched participants who had a first-mover advantage.

On the flip side of the equation, as a taker, I almost always never get the shares I want at the price I want when I want or have fill rates of about 20-30%.

The higher the latency, the further down the tiers I go into obscure, bizarre symbols no one has ever heard of. Now the SEC is thinking about changing the pricing system for these obscure symbols as well.
 
Quote from hft_boy:

Oh, I forgot to answer this. Nothing is *wrong* with C++ per se. It is just hard to write, hard to read, hard to maintain, and generally messy/ugly. Especially -- who the f*** came up with templated code? It kind of makes sense, but is impossible to work with. FWIW my C++ is basically C with some classes for reusable code and the occasional std::vector. Even std::string makes me shudder :P. I think it is just std::vector<char>. Like, seriously? Is that really necessary?
More...

I use templates heavily. I feel like C++ is useless without them. And now, with C++11, I feel like C++03/98 are broken. How we got by without lambdas, constexpr, auto, decltype, and rvalue references is just a mystery to me, even though I lived through these years of abuse.

Lambdas in particular, because it was a real pain to write functors off on the side, give them names, put them into the appropriate files, and use them.

The only thing missing for me that I feel is really critical is variadic templates, but the compilers I use on all platforms don't support them so I haven't been able to integrate them into my work.
 
Quote from clearinghouse:

I use templates heavily. I feel like C++ is useless without them. And now, with C++11, I feel like C++03/98 are broken. How we got by without lambdas, constexpr, auto, decltype, and rvalue references is just a mystery to me, even though I lived through these years of abuse.

Lambdas in particular, because it was a real pain to write functors off on the side, give them names, put them into the appropriate files, and use them.

The only thing missing for me that I feel is really critical is variadic templates, but the compilers I use on all platforms don't support them so I haven't been able to integrate them into my work.
More...

Also, the threading library is a huge improvement. But compiler support has been so terrible, I had to buy the third party library to get it to work. But even after buying the library, I find that thread local storage variables aren't supported properly in all compiler environments, so I sit around with ugly, messy legacy code everywhere. But, in due time, in due time....
 
Quote from hft_boy:

Oh, I forgot to answer this. Nothing is *wrong* with C++ per se. It is just hard to write, hard to read, hard to maintain, and generally messy/ugly. Especially -- who the f*** came up with templated code? It kind of makes sense, but is impossible to work with. FWIW my C++ is basically C with some classes for reusable code and the occasional std::vector. Even std::string makes me shudder :P. I think it is just std::vector<char>. Like, seriously? Is that really necessary?
More...

Guess it was inevitable that this thread would degenerate into a language debate eventually :-)

C++ seems complicated because of the vast array of features that the language designers provided. But no one said that you have to use all the features. Realize that "easier" languages like Java are just a sub-set of C++.

I remember reading somewhere that it is impossible to design a general-purpose language that is perfect for everyone - the only perfect language is one that is custom-designed for the project.

Now, it's impractical to design your own language for each project. But C++ kinda lets you do that by offering a vast set of features and allowing you to choose a sub-set. C++ can be as easy as Java if you stick to features that you think are needed for your project and avoid others in a disciplined manner.

Most of my projects, for example, treat heap-allocation as part of optimization (always declare on stack, and only insert "new/delete" later if profiling warrants it - which is almost never IME); avoid C-style arrays and use std::vector (which takes a small space on stack, and internally allocates on heap without you having to worry about memory); avoid multiple inheritance; write functions without side-effects; make objects immutable; minimal use of strings (never really need strings except for I/O - all internal representation can and should be done through integers); use STL as much as possible (no re-inventing wheels); no macros etc. etc.

Creating and diligently sticking to such rules lets me have the benefit of not having to worry about memory like GC languages, keeps things orderly and maintainable, while getting the C++ speed.

P.S. Don't have much experience (yet) with LLVM and static analysis, but from what I am reading, things will get even easier to code in C++.
 
The thread's topic seems to involve too many other sub-topics and instead of discussing why C++ is bad or not for ATSs (although no one could argue this language is by far the most frequently used especially in the HFT) I would propose a short list of questions for those interested:

a) How latency sensitive shout the ATS be? Do we care about milliseconds?

b) What programming langues do brokers APIs support?

c) What OSs do we favor? Stick to MS or think about cross-platformity?

d) Are we extensively back-testing with tick-by-tick data or bar data is sufficient?

e) Do we have legacy code to maintain?

f) What's the time to market? Do you know that you can write trading applications in Python too or even excel?

g) Very important: how much $$$ and time can we afford to spend for this job? Should this project be financed by the day-to-day's job revenues or we just won a couple of millions in a lottery and are willing to hire also a team of gurus?

h) What about legal stuff? In some cases you have to comply with local regulations, which are getting tougher and tougher.

My 2 cents about the programming language of choice: if I don't care about milliseconds and back-tests with tick-by-tick data, but need to build scalable applications I use C# (I'm just not so proficient in Java), otherwise I stick to some simple guidelines similar to what sidm listed and do C++ and I'm very happy with that.

Btw, there's an entire book about this topic (http://www.amazon.com/Building-Automated-Trading-Systems-Introduction/dp/0750682515) ... it has some nice ideas, but I wouldn't spend too much time with it.
For me personally, Building Automated Trading systems is like painting for an artist ... each painting is very different from the previous.
 
@NetTecture: True, that!

@clearinghouse: Yeah, it's a problem haha. The idea is to only trade things when they are so mispriced that blow throughs 'are okay'. What is wrong with pthread? Well I don't really use threads in my code anyways.

@sidm: Yeah, I was hoping to keep it away from language religion war but I guess it devolved a bit. C++ is actually our language of choice, at least a very restricted subset. It all comes down to style -- and nobody wins competitions for style because everybody hates everybody else's style! I think the key is to be really clear about the machine's state at all times throughout the code whether via immutable objects and no side-effect functions or comments and assertions or whatever it is.

@cvi: Thanks for the suggestions. I think that I want to keep this thread oriented towards architecting the code base of the project rather than 'practical' considerations. But to answer a couple of your questions anyways:

-- Regarding latency, code should be as fast as possible. Of course it doesn't make sense to optimize the shit out of something which makes one trade a day. But in my experience fast code is well written code and vice versa.

-- Used to use Windows, switched to Linux because it seemed better for programming and never looked back. Call me a dinosaur but command line tools are awesome.

-- How much time/money to spend on it? Whatever it takes to get it right. If you don't have money to pay for it, DO IT YOURSELF. If you don't spend enough time to get it right, well I hope you are happy when you end up like Knight.
 
Quote from hft_boy:
-- How much time/money to spend on it? Whatever it takes to get it right. If you don't have money to pay for it, DO IT YOURSELF. If you don't spend enough time to get it right, well I hope you are happy when you end up like Knight. [/B]
More...

Yeah. Like using NinjaSucker - ah - NinjaTrader. We had a strategy in staging environment, trading against a broker provided sim environment (i.e. non local). That is by our dev standard the last stage before going cash. As ninja backtest sucks, we used a 4-6 week staging cycle to find code issues.

One day - the sim account is LOOOONG a specific contract. VERY long.

Check finds out - a "-1" was closed at market. Turned into buying 122 lots, so the end result was +121 lots, the strategy saw neutral and no trace in the log file of the order - ninja issue.

That day I decided that crap goes OUT.

"Make it right or let it be".
 
welcome to reality, where things are complex.

Quote from NetTecture:

What is wrong is that there is not a single C++ compiler on this world that implements the whole langauge spec - it is that complex to do (there is anarcane feature in templates missing in every one, status is it is thought impossible to implement). Even the designer who did C## has said in an interview he would do things different a second time - very different.
More...
 
o rly? stop firing off buzzwords like its an exam. boost has been around for over 5 years now. fail.

Quote from clearinghouse:

I use templates heavily. I feel like C++ is useless without them. And now, with C++11, I feel like C++03/98 are broken. How we got by without lambdas, constexpr, auto, decltype, and rvalue references is just a mystery to me, even though I lived through these years of abuse.

Lambdas in particular, because it was a real pain to write functors off on the side, give them names, put them into the appropriate files, and use them.

The only thing missing for me that I feel is really critical is variadic templates, but the compilers I use on all platforms don't support them so I haven't been able to integrate them into my work.
More...
 
You must log in or register to reply here.
Back
Top