4 ms·

what language do you think would be the backbone for such a system? C/C++/Golang or something high level like node.js/Java

defrost 3y ago
Each to their own but if you read and understand the comment above they're describing a dedicated OS for the task .. so think about what you'd choose to write a small task dedicated OS with. Simple C is most likely, ASM is possible, a language such as OCaml generating C to hook into the low level buffers would be intriguing ... the list is long and largely determined by the experience preference of whoever tackles it. The major features for performance are to allocate and manage all memory from the start .. determine your thresholds of performance and put everything required together on cold start so as to avoid any thrashing at runtime.
- onetimeuse92304 3y ago
  You are surprisingly accurate. I used combination of Common Lisp (SBCL), ANSI C and assembly (not much assembly, though, only very small pieces that I had trouble emitting other ways). The main application was in Lisp, it would start up and set up the environment (using some low level code written in C/assembly). But everything on the path of the market signal to order would be highly optimised native machine code, but some of that code would be written in C and some of it would be compiled at runtime with Lisp. Parsing the incoming multicast feed from the exchange was implemented with Lisp emitting super efficient machine code (almost no function calls) based on a bunch of XML files describing the messages. I shamelessly stole the idea from the book Practical Common Lisp (really good if you want to get into Lisp). Things like business rules would be compiled into decision trees using current market situation and decision trees would be reorganised, optimised and compiled into machine code and inserted into the processing path. Most of the time a very large decision tree with hundreds of complex decisions (for example, taking into account market volatility) could be distilled to just couple branching instructions. This decision tree compilation would happen after every market signal, up to 10 thousand times a second (the exchange had a basic tick of 1/10000 of a second giving me guaranteed 100us before the next market signal). Same with actual algorithms -- I wrote a small DSL for the traders and this DSL would be compiled with Lisp to machine an inserted into the processing path. Some parts of the framework would be built with Lisp, too. It was easier for me to write a DSL and then compile it to machine than to write it in C. If you want to understand one principle from all this is to look at all instructions and especially branches that you have between receiving the signal and emitting the order and try to figure out if you can eliminate it and if you can't, try to find ways to do it ahead of time even if doing it ahead of time requires a lot more effort.
  - defrost 3y ago
    Not my first rodeo :-) I too made a real time hardware level trading system back in the day, on the back of building a multi channel seismic aquisition system with a custom RealtimeOS talking to a bunch of DSP cards that each sampled a trailing flotation cable that each had multiple microphones with the entire grid going toward building up a profile of the seafloor and layers underneath along with bobbing boat|cable cancelation, etc. Very similar architectures in many ways - with rolling DSP filters in place of trading response algorithms .. etc. Lisp -> ASM or Lisp -> C either way code generation from a higher language was a good way to get the heavy lifting done.
    - onetimeuse92304 3y ago
      Cool project! I guess when different people try to achieve extreme low latency or efficiency, the solutions start to converge into small number of ideas.
    - vivzkestrel 3y ago
      what would you do if you wanna run all this on a web server instead? sorry if thats the wrong question. how does your system interact with say android or ios clients or a webapp with ui
      - onetimeuse92304 3y ago
        If you have a project that you want to see done, you will be more likely to succeed using some more traditional architecture. What I described is chasing latency at all costs. The costs are hardware costs, maintainability costs, development costs, inefficiency (yes, a lot more CPU is used than what is needed just to run the critical path fast). This is very extreme situation and it would be very unlikely to be a good tradeoff for your application. If you have a lot of clients connecting there are different tradeoffs to think about and different possible architectures to evaluate, but I can't help you not knowing what your problem is.
      - twic 3y ago
        The low-latency core communicates with a more normal app via messages, over a socket or through shared memory or whatever. So you have normal UI code where a user can enter an instruction, then instead of writing to a database or making a HTTP request, it sends a message to the low latency process. That should respond to acknowledge it, and it will send more messages later if it makes any trades etc.
- twic 3y ago
  My team did it in Rust. Others in our company have done it in C++, making heavy use of available wizardry. It's widespread in the industry to do it in Java, albeit a strange subset of Java where you avoid most of the features. I'd be amazed if anyone did it entirely in C. The productivity is just too low.
  - onetimeuse92304 3y ago
    The question really is "why?" Most systems have relatively few hotspots or can be reorganised to have relatively few hotspots. You don't need to write everything in a low level language to just have those few things run fast, unless you are also facing other constraints like low memory. I have better uses of my time than write megabytes of pointer manipulation in C. That's why I prefer high level languages that can easily coexist with C for those few parts that really benefit.
    - pjmlp 3y ago
      So are the wonders of polyglot programming, too many devs are too focused on the one language for everything. Since 2006 that the projects I work on follow a similar approach, Java, C# and nowadays node as well, coupled with C++ when required.
    - gpderetta 3y ago
      A trading system doesn't have a single hot spot that can be easily optimized. The critic paths can be hundreds of thousands of line of code. There a lot of separate processes and subsystem that do not need to be absolutely latency optimal (or even at all), that are definitely amenable to be written on other languages. Of course when you already have a bunch of C++ programmes, things tend to end up being written in C++ even if it is not strictly necessary.
marginalia_nu 3y ago
I wouldn't bundle C with Golang and Java with Node. Golang and Java are roughly a tier on their own. Java is definitely a thing in this space[1], although it's a fairly unidiomatic style of Java that reduces allocations and puts a lot of emphasis on consistent low latency. [1] e.g. https://marketswiki.com/wiki/TRADExpress https://marketswiki.com/wiki/TRADExpress ; though they've been absorbed into Nasdaq now and my visibility into CFT ended with that, no idea how much of their software is still running
- pjmlp 3y ago
  Hopefully Panama will help to make it better, and there is still hope for Valhala.

defrost 3y ago

Each to their own but if you read and understand the comment above they're describing a dedicated OS for the task .. so think about what you'd choose to write a small task dedicated OS with. Simple C is most likely, ASM is possible, a language such as OCaml generating C to hook into the low level buffers would be intriguing ... the list is long and largely determined by the experience preference of whoever tackles it. The major features for performance are to allocate and manage all memory from the start .. determine your thresholds of performance and put everything required together on cold start so as to avoid any thrashing at runtime.

onetimeuse92304 3y ago
You are surprisingly accurate. I used combination of Common Lisp (SBCL), ANSI C and assembly (not much assembly, though, only very small pieces that I had trouble emitting other ways). The main application was in Lisp, it would start up and set up the environment (using some low level code written in C/assembly). But everything on the path of the market signal to order would be highly optimised native machine code, but some of that code would be written in C and some of it would be compiled at runtime with Lisp. Parsing the incoming multicast feed from the exchange was implemented with Lisp emitting super efficient machine code (almost no function calls) based on a bunch of XML files describing the messages. I shamelessly stole the idea from the book Practical Common Lisp (really good if you want to get into Lisp). Things like business rules would be compiled into decision trees using current market situation and decision trees would be reorganised, optimised and compiled into machine code and inserted into the processing path. Most of the time a very large decision tree with hundreds of complex decisions (for example, taking into account market volatility) could be distilled to just couple branching instructions. This decision tree compilation would happen after every market signal, up to 10 thousand times a second (the exchange had a basic tick of 1/10000 of a second giving me guaranteed 100us before the next market signal). Same with actual algorithms -- I wrote a small DSL for the traders and this DSL would be compiled with Lisp to machine an inserted into the processing path. Some parts of the framework would be built with Lisp, too. It was easier for me to write a DSL and then compile it to machine than to write it in C. If you want to understand one principle from all this is to look at all instructions and especially branches that you have between receiving the signal and emitting the order and try to figure out if you can eliminate it and if you can't, try to find ways to do it ahead of time even if doing it ahead of time requires a lot more effort.
- defrost 3y ago
  Not my first rodeo :-) I too made a real time hardware level trading system back in the day, on the back of building a multi channel seismic aquisition system with a custom RealtimeOS talking to a bunch of DSP cards that each sampled a trailing flotation cable that each had multiple microphones with the entire grid going toward building up a profile of the seafloor and layers underneath along with bobbing boat|cable cancelation, etc. Very similar architectures in many ways - with rolling DSP filters in place of trading response algorithms .. etc. Lisp -> ASM or Lisp -> C either way code generation from a higher language was a good way to get the heavy lifting done.
  - onetimeuse92304 3y ago
    Cool project! I guess when different people try to achieve extreme low latency or efficiency, the solutions start to converge into small number of ideas.
  - vivzkestrel 3y ago
    what would you do if you wanna run all this on a web server instead? sorry if thats the wrong question. how does your system interact with say android or ios clients or a webapp with ui
    - onetimeuse92304 3y ago
      If you have a project that you want to see done, you will be more likely to succeed using some more traditional architecture. What I described is chasing latency at all costs. The costs are hardware costs, maintainability costs, development costs, inefficiency (yes, a lot more CPU is used than what is needed just to run the critical path fast). This is very extreme situation and it would be very unlikely to be a good tradeoff for your application. If you have a lot of clients connecting there are different tradeoffs to think about and different possible architectures to evaluate, but I can't help you not knowing what your problem is.
    - twic 3y ago
      The low-latency core communicates with a more normal app via messages, over a socket or through shared memory or whatever. So you have normal UI code where a user can enter an instruction, then instead of writing to a database or making a HTTP request, it sends a message to the low latency process. That should respond to acknowledge it, and it will send more messages later if it makes any trades etc.
twic 3y ago
My team did it in Rust. Others in our company have done it in C++, making heavy use of available wizardry. It's widespread in the industry to do it in Java, albeit a strange subset of Java where you avoid most of the features. I'd be amazed if anyone did it entirely in C. The productivity is just too low.
- onetimeuse92304 3y ago
  The question really is "why?" Most systems have relatively few hotspots or can be reorganised to have relatively few hotspots. You don't need to write everything in a low level language to just have those few things run fast, unless you are also facing other constraints like low memory. I have better uses of my time than write megabytes of pointer manipulation in C. That's why I prefer high level languages that can easily coexist with C for those few parts that really benefit.
  - pjmlp 3y ago
    So are the wonders of polyglot programming, too many devs are too focused on the one language for everything. Since 2006 that the projects I work on follow a similar approach, Java, C# and nowadays node as well, coupled with C++ when required.
  - gpderetta 3y ago
    A trading system doesn't have a single hot spot that can be easily optimized. The critic paths can be hundreds of thousands of line of code. There a lot of separate processes and subsystem that do not need to be absolutely latency optimal (or even at all), that are definitely amenable to be written on other languages. Of course when you already have a bunch of C++ programmes, things tend to end up being written in C++ even if it is not strictly necessary.

marginalia_nu 3y ago

I wouldn't bundle C with Golang and Java with Node. Golang and Java are roughly a tier on their own. Java is definitely a thing in this space[1], although it's a fairly unidiomatic style of Java that reduces allocations and puts a lot of emphasis on consistent low latency. [1] e.g. https://marketswiki.com/wiki/TRADExpress https://marketswiki.com/wiki/TRADExpress ; though they've been absorbed into Nasdaq now and my visibility into CFT ended with that, no idea how much of their software is still running

pjmlp 3y ago
Hopefully Panama will help to make it better, and there is still hope for Valhala.