4 ms·

Latency is the first thing that comes to mind. This can be dealt with in a few ways: 1. Co-lo at the same data centers as your broker. exchanges, etc 2. zero

Latency is the first thing that comes to mind. This can be dealt with in a few ways: 1. Co-lo at the same data centers as your broker. exchanges, etc 2. zero-copy, kernel bypass techniques. 3. machines are locked down, striped down of services, fast CPU, disk, lots of RAM. But there are still lots of other issues like retrieving data, processing it, working with it, etc. I'd be happy to elaborate on anything.

dmos62 8y ago
Ok, I'll pick your brain a bit more. I presume when we're talking about such ultra low latency systems the software stack is uniquely manual memory management languages, or maybe I should say non-gc, with Rust gaining traction. At the same time the LMAX exchange runs on JVM, as far as I know. Reading some opinions you feel like for low-latency a GC language is a no-go. Maybe you care to comment on that. Generally, I feel like when discussing these systems the wow factor of "speed of light is a factor" dwarfs the more mundane aspects. Maybe it would be enlightening to consider slower 1ms max pause systems. With such requirements you don't care about being within earshot of the exchange anymore, and you'll probably not use FPGAs, but you still need latency that is deterministic and low. When a software engineer has to develop such a system, what are the challenges, considerations, etc?
- jason_slack 8y ago
  Well, a lot of places are using Java, Python or C++. I know one guy that uses C#. Python is used a lot as there are a lot of libraries available, lots of built in functionality for parsing large datasets, files, lots of math functions, etc. I prefer c++ but I am bias since I have been using it for 25 years. I am now doing a prototype in Python but then re-writing in C++ for production. This helps gain speed and also ensures my ideas are solid as re-writing usually flushes out problems or things I didn't think of originally.
- phakding 8y ago
  > Reading some opinions you feel like for low-latency a GC language is a no-go. Maybe you care to comment on that. This is false as far as my experience goes. I've personally worked at two exchanges (big ones) and they do use java. Also have interviewed with many trading firms that use java for trading platform.
  - jason_slack 8y ago
    I look at algo/quant jobs everyday and indeed Java is heavily used in some companies. Back in the early 2000 when I was using servlets and Swing Java was always considered slow. Now I feel like we should give it a second chance as it's come a long way from then.
  - zygotic12 8y ago
    Source HSBC. They just re-write the GC to perform as required.
    - phakding 8y ago
      Rewriting GC seems like a serious overkill. One could achieve serious low latency with hotspot.
      - zygotic12 8y ago
        Nothing is overkill for these guys. Cross-pollination from the whole business including HFT.
        jason_slack 8y ago
        Well, I think I can feel you here. I examine everything right now trying to shave anything I can off my implementations. From stripped down OS to code to NIC brand, etc.

dmos62 8y ago

Ok, I'll pick your brain a bit more. I presume when we're talking about such ultra low latency systems the software stack is uniquely manual memory management languages, or maybe I should say non-gc, with Rust gaining traction. At the same time the LMAX exchange runs on JVM, as far as I know. Reading some opinions you feel like for low-latency a GC language is a no-go. Maybe you care to comment on that. Generally, I feel like when discussing these systems the wow factor of "speed of light is a factor" dwarfs the more mundane aspects. Maybe it would be enlightening to consider slower 1ms max pause systems. With such requirements you don't care about being within earshot of the exchange anymore, and you'll probably not use FPGAs, but you still need latency that is deterministic and low. When a software engineer has to develop such a system, what are the challenges, considerations, etc?

jason_slack 8y ago
Well, a lot of places are using Java, Python or C++. I know one guy that uses C#. Python is used a lot as there are a lot of libraries available, lots of built in functionality for parsing large datasets, files, lots of math functions, etc. I prefer c++ but I am bias since I have been using it for 25 years. I am now doing a prototype in Python but then re-writing in C++ for production. This helps gain speed and also ensures my ideas are solid as re-writing usually flushes out problems or things I didn't think of originally.
phakding 8y ago
> Reading some opinions you feel like for low-latency a GC language is a no-go. Maybe you care to comment on that. This is false as far as my experience goes. I've personally worked at two exchanges (big ones) and they do use java. Also have interviewed with many trading firms that use java for trading platform.
- jason_slack 8y ago
  I look at algo/quant jobs everyday and indeed Java is heavily used in some companies. Back in the early 2000 when I was using servlets and Swing Java was always considered slow. Now I feel like we should give it a second chance as it's come a long way from then.
- zygotic12 8y ago
  Source HSBC. They just re-write the GC to perform as required.
  - phakding 8y ago
    Rewriting GC seems like a serious overkill. One could achieve serious low latency with hotspot.
    - zygotic12 8y ago
      Nothing is overkill for these guys. Cross-pollination from the whole business including HFT.
      - jason_slack 8y ago
        Well, I think I can feel you here. I examine everything right now trying to shave anything I can off my implementations. From stripped down OS to code to NIC brand, etc.