Technology stack for a high freq low lat trading system

[d000hg]

I'd avoid using QT for anything other than the GUI, and structure your code in a way that the GUI component is completely seperate from all the bits that do the work. Qt can be quite good for GUI, but I wouldn't suggest using it for anything else.

Decent advice whatever GUI toolkit you use, though both Qt and wx provide a whole slew of utilities which could be useful given that C++ is missing the massive standard libraries offered by Java/.NET.

Another option is to write your core engine 100% GUI-independent (i.e. as a library) and then build separate per-platform native GUIs on top. If you want very slick GUI I'd have to recommend that way, if you want something workmanlike and the same on all systems, use a cross-platform kit.

std::thread pretty much is boost::thread, just incorporated into the main library.

Isn't the truthfulness of that statement very compiler-dependent... many of us are still using VC++ 2008 and the differences between 2008->2011, or between VC++ and GCC, can be significant.

[VectraMan]

Basically every programming language will get a fast runtime, given enough attention - see what's happening to Javascript these days.

I did some work incorporating Google v8 into a C++ application; this was about the time there was all the hype over fast Javascript engines that settled down a little now. Sure enough it was pretty fast at running pure javascript (still a fair bit slower than native), but there was quite a big overhead anytime the script had to call C++ functions, which is after all the point. And then there was the garbage collection problem. I remember timing something repeatedly, and it was consistently running in 4-5ms, then every now and again would take 200ms. This was controlling animation, so the delay resulted in a noticeable onscreen stutter, which wasn't really acceptable.

[VectraMan]

Isn't the truthfulness of that statement very compiler-dependent... many of us are still using VC++ 2008 and the differences between 2008->2011, or between VC++ and GCC, can be significant.

Maybe. I'm not sure what's in 2008, do you have all that tr2 stuff?

[d000hg]

Not sure but if we do it's surely not part of std:: in which case one might as well use boost.

[bilgehan]

Another option is to write your core engine 100% GUI-independent (i.e. as a library) and then build separate per-platform native GUIs on top. If you want very slick GUI I'd have to recommend that way, if you want something workmanlike and the same on all systems, use a cross-platform kit.

Yeah that's a good idea. Only problem is I have to convert data to/from QT std such as std::string to QString. Anyway that's some performance overhead needs to be paid in order to enable crossplatform development.

[bilgehan]

some managers have though of Java as a safe bet, even for a trading platform - avaialble pool of programmers, rates, potential for outsourcing etc..
From a pure performance point of view, it's a very poor choice indeed, but has other advantages like rich set of frameworks and libraries for pretty much everything.

I asked about Java just for clarification. As I am a C++ developer Java is out of the equation anyway.

If you want to develop a fast trading platform, you definitely need to write in a low-level code, but only the bits that matter. GUI stuff etc can simply be some form of a website form, so even QT might be an overkill.

It is also interesting to understand what your goals are in this and where do you want to position the project - clearly you're not going for the fastest crown (otherwise, you'd need to design custom FPGA chips and host the silicon in close physical proximity of the exchanges), probably just fast enough, in which case Java isn't such a bad choice actually, ideally coupled with a higher-level part like Scala or Groovy to generate all the boring stuff...

I don't have in mind designing custom FPGAs and other very high performance stuff. Maybe in the distant future.

I used MEtatrader platform for forex. Can write EAs etc. My first goal is to implement a trading system with an UI which simplifies trading: showing budget, have controls to switch between strategies and sending orders over Metarader. So in this case I'll have a UI a dll which communicates with MT and a running MT.

After that I need to access FIX Api via BARX or something else and get rid of MEtatrader that's when I can switch to Linux. At the end I'll have a system which can make strategy decisions and send orders via FIX Api. But that's another problem I haven't thought throughly. I don't know whether I can access FIX without having a company and being a standalone trader. Also not aware of any FIX alternative or companies providing real time access to markets.

[Spacecadet]

StreamInsight already has FIX adapters

Synthesis Consulting, Inc - blog - StreamInsight and FIX, Part 1

StreamInsight: FIX – Well Done Torsten Grabs (MSFT) « Tales from a Trading Desk

StreamInsight Team : FIX adapter for StreamInsight

[d000hg]

Yeah that's a good idea. Only problem is I have to convert data to/from QT std such as std::string to QString. Anyway that's some performance overhead needs to be paid in order to enable crossplatform development.

Really, they force you to use their own String type? How very 1999.

[bilgehan]

StreamInsight already has FIX adapters

Synthesis Consulting, Inc - blog - StreamInsight and FIX, Part*1

StreamInsight: FIX – Well Done Torsten Grabs (MSFT) « Tales from a Trading Desk

StreamInsight Team : FIX adapter for StreamInsight

Thanks for the links. I didn't notice this when you first pointed to StreamInsight, very helpfull indeed.

[SupremeSpod]

But doesn't Java have to stop the world every now and again and have a bit of a think and a garbage collect?

Our Java code is Garbage Free, and very low latency.