Perhaps not a satisfactory response but when I start drifting towards thinking FP is fundamentally not as performant as _whatever_else_, I remember that Jane Street uses OCaml basically from top to bottom, and they certainly can't be too slow... Some black magic going on there.
The "oh no it's slow, and you can't reason about performance" FUD is mostly directed at Haskell's lazy evaluation, but people like to throw it vaguely in the direction of "FP" in general. Most of the performance problems you have in Haskell (as in this recent submission: https://news.ycombinator.com/item?id=21266201) are not problems you will have in OCaml.
Yes, OCaml has garbage collection. It's a very efficient GC, and it is only ever called when you try to allocate something and the system determines that it's time for cleanup (https://ocaml.org/learn/tutorials/garbage_collection.html, though this might change if/when Multicore OCaml ever happens?). So if you write an innermost function that does arithmetic on stuff but never allocates data structures, you will not have GC problems because you will not have GC during that time, period.
Also, there are cases where destructive mutation of things is more efficient than making pure copies. OCaml allows you to do that, you don't need to fiddle with monads to simulate state.
There really isn't that much black magic there. Just don't believe everything that is said about "FP".
My understanding is that OCaml is a decent imperative language when required and that's one reason why it can perform well.
My usual issue with the 'you can avoid the GC by not allocating' claims in any language, is how much of the language is still usable? Which features of the language allocate under the hood? Can I use lambdas? pattern matching? list compression or whatever nice collection is available in the language?
Note that I do agree that even in very high performance/low latency applications, there will be components (even a majority of them) that will be able to afford GC without issues; but then it is important to be able to isolate the critical pieces from GC pauses (for example, can I dedicate one core to one thread and guarantee that GC will never touch that thread?)
Not ones that capture anything from the environment. I'm not sure about ones that don't, but I imagine you can use them.
> pattern matching?
Yes.
> list compression
List comprehensions, you mean? They don't exist in OCaml, but if they did, they would have to allocate a result list. So no.
> for example, can I dedicate one core to one thread and guarantee that GC will never touch that thread?
I don't think so, maybe someone else can chime in. But more importantly, this is a one-in-a-million use case that is a far cry from "functional programming is always bloated and slow and unpredictable". GC is well-understood, advanced, and comfortably fast enough for most applications. And for other cases, if you really need that hot innermost part, write it in C and call that from OCaml if you're paranoid about it.
Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speeding up code written in a straightforward fashion. Possibly also turning lists into arrays secretly too if it can be proven to produce the same result.
The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner.
Personally, I think consistency is more important here because it leads to better predictability. If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a lot of nasty debugging issues.
Jane Street wrote a compiler that converts Ocaml to Verilog which they run on FPGAs. The OCaml you write in that case is pretty different than what you write for CPUs.
Although I don’t work directly with the FPGA stuff, it’s still a very, very small piece of the overall pie (and new).
The motivation behind using Ocaml is mainly in its correctness(!) not because it’s fast (it’s not). See Knight Capital for a good example as to why. There are great videos on YT by Yaron Minsky that explain this better than I can.
Speaking of correctness and performance, was Ada/SPARK ever considered before you guys picked OCaml? Hypothetically, would you consider Ada/SPARK now, especially that SPARK has safe pointers and whatnot?
While Knight Capital's problem was caused by incompatible versions of the software talking to each other, one of the reasons that happened was the deployment of the code was not correct. The SEC notes:
> “During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.
Rumor on the outside suggests that Jane St uses OCaml for things like deploying software.
There are really many places in code where you really don't care about performance that much. And in that case conciseness/expressiveness/correctness can be extremely valuable.
Also there are different aspects to performance, and when (for example) it comes to latency, a platform like Erlang/BEAM makes it particularly easy to get low latency in certain contexts without thinking about implementation much. In Haskell you can accomplish similar things with green threads. It will probably need more clock cycles for a given action than a tuned C implementation but that's not always what matters, and the code will probably be cleaner.
Is the kind of HFT that Jane Street does that reliant on extremely low latency? A lot of HFT firms operate on the timescale of seconds, minutes, or even hours, not milliseconds.
I feel like there must be terminology confusion here - the HF in HFT stands for high frequency, which effectively means low latency. There may be HFT firms that additionally do slower stuff, but no one would call a trade on the timescale of hours HFT - it's a fuzzy line, but certainly nothing measured in units larger than microseconds would qualify to someone in the industry, and the line is likely lower than that.
