• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.

Technology stack for a high freq low lat trading system

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Technology stack for a high freq low lat trading system

    Hi,

    I am curious about real life examples of technology stacks of high frequency trading companies. I am in the planning stage of my own ATS but a bit confused about the pieces such as GUI, threading.. I am a C/C++ dev so want to code in C++.

    First problem was to choose between Windows and Linux. I decided to make it crossplatform but open to a single platform solution as well.
    I checked QT for crossplatform GUI development but I think mixing it with boost would be problematic like using QT for UI and using boost threads. Also I have no experience with QT so I don't know whether it'll worth to dive in it.

    So If you ever worked in hedgefund or trading company and can give me some hints that would be helpfull. It seems most of the trading companies use linux as
    their platform do you have any idea about their GUI toolkit, threading libs(QT threads, boost threads, plain pthreads) etc?

    Btw I noticed plenty of Java ads from HFT companies like this one Senior Core Java Developer/Senior Java High Frequency Trading: Tier 1 Investment Bank job - London - April-02-2012 (CxIv7) and a bit confused as I always thought Java would be slow for such a system?

    #2
    There's no problem with mixing Qt and boost (or any other )threads, but Qt does restrict you to updating the screen in its one GUI thread.
    Will work inside IR35. Or for food.

    Comment


      #3
      Streaminsight from Microsoft is worth a look. Its currently bundled with SQL Server - although it's more of a .NET addon than a database product
      Coffee's for closers

      Comment


        #4
        I'm a fan of wxWidgets.
        Originally posted by MaryPoppins
        I'd still not breastfeed a nazi
        Originally posted by vetran
        Urine is quite nourishing

        Comment


          #5
          Originally posted by bilgehan View Post
          Btw I noticed plenty of Java ads from HFT companies like this one Senior Core Java Developer/Senior Java High Frequency Trading: Tier 1 Investment Bank job - London - April-02-2012 (CxIv7) and a bit confused as I always thought Java would be slow for such a system?
          They nailed the speed issues quite some time ago, as long as you set up the JVM correctly and don't write poor code it can handle low latency stuff just fine.

          Comment


            #6
            Originally posted by minestrone View Post
            They nailed the speed issues quite some time ago, as long as you set up the JVM correctly and don't write poor code it can handle low latency stuff just fine.
            But doesn't Java have to stop the world every now and again and have a bit of a think and a garbage collect?
            Will work inside IR35. Or for food.

            Comment


              #7
              Originally posted by VectraMan View Post
              But doesn't Java have to stop the world every now and again and have a bit of a think and a garbage collect?
              That's what I've always thought, too.

              I am inclined to go to QT+QT threads path and won't touch boost instead will replace qt threading C++11 std::thread if needed when std threads are ready.

              Comment


                #8
                Originally posted by bilgehan View Post
                That's what I've always thought, too.

                I am inclined to go to QT+QT threads path and won't touch boost instead will replace qt threading C++11 std::thread if needed when std threads are ready.
                Basically every programming language will get a fast runtime, given enough attention - see what's happening to Javascript these days.
                It's not hard to understand why 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.

                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...

                Comment


                  #9
                  Originally posted by bilgehan View Post
                  I am inclined to go to QT+QT threads path and won't touch boost instead will replace qt threading C++11 std::thread if needed when std threads are ready.
                  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.

                  std::thread pretty much is boost::thread, just incorporated into the main library. So you'd be much better off using boost::thread and then changing to std::thread could be as simple as a search and replace of boost:: to std::. You won't get that if you go down the Qt route.
                  Will work inside IR35. Or for food.

                  Comment


                    #10
                    Originally posted by minestrone View Post
                    They nailed the speed issues quite some time ago, as long as you set up the JVM correctly and don't write poor code it can handle low latency stuff just fine.
                    Originally posted by VectraMan View Post
                    But doesn't Java have to stop the world every now and again and have a bit of a think and a garbage collect?
                    Yes this is still an issue... I assume clever people have found ways around it but if you are writing from scratch I'd wave this as a big red flag until you can research properly.
                    Originally posted by MaryPoppins
                    I'd still not breastfeed a nazi
                    Originally posted by vetran
                    Urine is quite nourishing

                    Comment

                    Working...
                    X