3 ms·

So you had to switch to C++ because Clojure / Java wasn't performant enough?

chollida1 3y ago
> So you had to switch to C++ because Clojure / Java wasn't performant enough? Clojure yes, java no. Many HFT firms build their systems in java and run on the jvm(specialized hardware aside), its plenty fast if you avoid memory allocations. It is also possible Clojure is more than up to the task now and its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues at the time and a more competent developer could have made it work. But like almost all things if you chose a very out of the mainstream language and start to have issues, most developers will point fingers at the language first. Side note, its a miracle that Jane Street kept using OCaml after the first few years and points to how strong their core tech team was. C++ was an external dependency brought on by other systems that needed to be integrated and is a far safer language to use. I'd imagine that if you say HFT to most developers, their first thought would be C++ even if they haven't worked in the domain before. It's like choosing Julia for your machine learning platform and then switching to python.
- Jach 3y ago
  It's a shame you couldn't have pitched Common Lisp. Maybe could have ported your DSL pretty quickly and wound up having SBCL output nice compiled assembly instructions and shown x% speed improvement without much effort by using a "sister language" of sorts? ABCL in 2011 would have been a harder sell, it only had its 1.0 release that October. A few years ago another commenter noted they had developed a trading system in Lisp and C https://news.ycombinator.com/item?id=25222297 https://news.ycombinator.com/item?id=25222297 (further comments elaborate a bit) before being asked to rewrite it in Java. What keeps less popular languages alive at companies, when there's no forcing reason to get rid of it like really unacceptable performance, is a conviction (borne out as far as I can tell) that it's ok to hire people who don't know the language -- they'll get up to speed more than fast enough.
- roenxi 3y ago
  > ... its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues... Technically it can likely be done but in practice pushing Clojure code for performance (eg, [0]) doesn't follow the usual language idioms and relies on a sophisticated understanding of the interactions between program design, Clojure, the Clojure compiler and the JVM. I'd suggest pointing more at the language than the programmer. In a situation where direct memory management is required Clojure is a weaker choice. Although in Clojure's defence it leverages immutability to squeeze out some surprising performance benefits without much effort. I would expect Clojure code to be fast by default but challenging to hand-optimise further if that extra level of control is required. Clojure makes it easy to write code that performs well, it is a stronger language for situations where ordinary business logic changes are the productivity bottleneck. [0] https://blog.redplanetlabs.com/2020/09/02/clojure-faster/ https://blog.redplanetlabs.com/2020/09/02/clojure-faster/
WinLychee 3y ago
For extremely low latency, Clojure can be an awkward fit. By default there's a lot of sugar in the syntax, so if you need to be precise about the underlying types of your data and the exact datastructure, you need to toss out most of the standard datatypes and datastructures. It's small details like: "I definitely have an array of unboxed integers, and I need to be sure this one operation won't accidentally allocate a new list of boxed integers, and that this function I'm calling doesn't dispatch dynamically" or things like that. You start using `deftype` everywhere, sometimes dipping into Java, etc. You may as well just write java at that point. However from a pure Clojure standpoint, the author of Neanderthal has done great work on making Clojure viable for high performance numerical computing.
jwr 3y ago
> because Clojure / Java wasn't performant enough Languages aren't "performant". You can write good or bad code in most languages, or code that isn't a good fit for a language. That said, there are languages which will make you incur certain penalties, as there is a price to be paid for automatic memory management with garbage collection, for example. These penalties generally do not matter except for edge cases (and HFT trading might very well be one!). There are also languages which help you write much faster code, but on a higher level. Clojure transducers are a good example: pipelines built of composable transformations, where data sequences are not fully realized between the transformations. These can provide significant performance (and memory allocation) improvements, while still letting you write high-level code.
- moomin 3y ago
  There is “the expected performance of idiomatic code”, though, which is what most people mean when they talk about the performance of a language.
  - jwr 3y ago
    Yes. And it really doesn't matter in practice. In a larger system this kind of performance won't matter. What will matter is design decisions, data structures, databases and access patterns — things that are much more high-level than "language performance".

> So you had to switch to C++ because Clojure / Java wasn't performant enough? Clojure yes, java no. Many HFT firms build their systems in java and run on the jvm(specialized hardware aside), its plenty fast if you avoid memory allocations. It is also possible Clojure is more than up to the task now and its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues at the time and a more competent developer could have made it work. But like almost all things if you chose a very out of the mainstream language and start to have issues, most developers will point fingers at the language first. Side note, its a miracle that Jane Street kept using OCaml after the first few years and points to how strong their core tech team was. C++ was an external dependency brought on by other systems that needed to be integrated and is a far safer language to use. I'd imagine that if you say HFT to most developers, their first thought would be C++ even if they haven't worked in the domain before. It's like choosing Julia for your machine learning platform and then switching to python.

Jach 3y ago
It's a shame you couldn't have pitched Common Lisp. Maybe could have ported your DSL pretty quickly and wound up having SBCL output nice compiled assembly instructions and shown x% speed improvement without much effort by using a "sister language" of sorts? ABCL in 2011 would have been a harder sell, it only had its 1.0 release that October. A few years ago another commenter noted they had developed a trading system in Lisp and C https://news.ycombinator.com/item?id=25222297 https://news.ycombinator.com/item?id=25222297 (further comments elaborate a bit) before being asked to rewrite it in Java. What keeps less popular languages alive at companies, when there's no forcing reason to get rid of it like really unacceptable performance, is a conviction (borne out as far as I can tell) that it's ok to hire people who don't know the language -- they'll get up to speed more than fast enough.
roenxi 3y ago
> ... its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues... Technically it can likely be done but in practice pushing Clojure code for performance (eg, [0]) doesn't follow the usual language idioms and relies on a sophisticated understanding of the interactions between program design, Clojure, the Clojure compiler and the JVM. I'd suggest pointing more at the language than the programmer. In a situation where direct memory management is required Clojure is a weaker choice. Although in Clojure's defence it leverages immutability to squeeze out some surprising performance benefits without much effort. I would expect Clojure code to be fast by default but challenging to hand-optimise further if that extra level of control is required. Clojure makes it easy to write code that performs well, it is a stronger language for situations where ordinary business logic changes are the productivity bottleneck. [0] https://blog.redplanetlabs.com/2020/09/02/clojure-faster/ https://blog.redplanetlabs.com/2020/09/02/clojure-faster/

WinLychee 3y ago

For extremely low latency, Clojure can be an awkward fit. By default there's a lot of sugar in the syntax, so if you need to be precise about the underlying types of your data and the exact datastructure, you need to toss out most of the standard datatypes and datastructures. It's small details like: "I definitely have an array of unboxed integers, and I need to be sure this one operation won't accidentally allocate a new list of boxed integers, and that this function I'm calling doesn't dispatch dynamically" or things like that. You start using `deftype` everywhere, sometimes dipping into Java, etc. You may as well just write java at that point. However from a pure Clojure standpoint, the author of Neanderthal has done great work on making Clojure viable for high performance numerical computing.

jwr 3y ago

> because Clojure / Java wasn't performant enough Languages aren't "performant". You can write good or bad code in most languages, or code that isn't a good fit for a language. That said, there are languages which will make you incur certain penalties, as there is a price to be paid for automatic memory management with garbage collection, for example. These penalties generally do not matter except for edge cases (and HFT trading might very well be one!). There are also languages which help you write much faster code, but on a higher level. Clojure transducers are a good example: pipelines built of composable transformations, where data sequences are not fully realized between the transformations. These can provide significant performance (and memory allocation) improvements, while still letting you write high-level code.

moomin 3y ago
There is “the expected performance of idiomatic code”, though, which is what most people mean when they talk about the performance of a language.
- jwr 3y ago
  Yes. And it really doesn't matter in practice. In a larger system this kind of performance won't matter. What will matter is design decisions, data structures, databases and access patterns — things that are much more high-level than "language performance".