10 ms·

If performance is THAT critical in HFT, why do they pick java as the starting language? I understand that java is very fast, faster than most people believe, b

• PaulHoule 10y ago
  It's close to impossible to get certain kinds of code correct in C, for instance, string parsing. Also until pretty recently, C and C++ did not have a sane memory model so what happened when threads was involved was dependent on what CPU you are on, the sign of the moon, etc. Java could very well be the first programming language designed by adults and it shows. (That is, they solve the hard problems, not just pretend they don't matter)
  • revelation 10y ago
    Eh it's HFT, I'm not sure there is much string parsing going on. Or variable length anything.
    • kasey_junk 10y ago
      Some exchanges use text based variable length message formats. String parsing is very much going on even though its the bane of HFT devs. That's going away as exchanges upgrade their gateways.
      • revelation 10y ago
        That's just plain terrible. But a good reminder that all the talk about nanoseconds is just that.
        • kasey_junk 10y ago
          The thing is, everybody has to deal with the string parsing, so speeding up your string parsing does have value even if its slow in relation to non-string based exchanges.
      • gpderetta 10y ago
        Yes, and you are going to write your string parsing routines from scratch, no matter what language you use.
  • vvanders 10y ago
    The amount of contortions you need to do with your "adult" language arguably negates a lot of advantages of using it. Just because you don't have pointers doesn't mean that all bugs are now eliminated. Take Android for instance, getting solid performance out of the JVM there is a huge bear because the language is just not suited to low latency operations. I won't claim that C is a perfect language but I hate it when I see people throwing around that you're committing some sin for each line of C code you write. If you want cache friendly operations and predictable performance you're not going to find it in any JVM or language that has a GC.
    • chollida1 10y ago
      > If you want cache friendly operations and predictable performance you're not going to find it in any JVM or language that has a GC. I don't know you and it's always dangerous to argue with people on HN due to who might be reading but I'd very strongly disagree with your above quote. Predictable performance can be obtained on a very low latency, I've seen it:) Cache friendly can be tougher and I won't argue the point as I think it will end up being a "no true Scotsman" argument where I claim Java can be cache efficient and you counter that C can do better so therefor Java isn't truly cache efficient
      • vvanders 10y ago
        That's true, I'm very familiar with tuning Java to be cache aware. I've played around with FlatBuffers[1] in my spare time to good effect which seems to be the only sane way of doing cache aware layout in Java. That said the amount of restrictions you have makes it really painful(needing to use pre-allocated wrappers if you want to read more than intrinsic types, not being able to grow/shrink anything). There's sun.misc.Unsafe, but that isn't available on every JVM implementation. A GC is going to by nature introduce pauses if since at some point it's going to need to do work on the memory you hold. There's a set of tunable tradeoffs but it will impact latency. I guess my meta point is if throughput and latency are paramount to you then you should really consider a language suited for it. For me today that would be Rust or C++ depending on how risk-adverse the organization you're working with is. [1] https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/
  • Negitivefrags 10y ago
    > It's close to impossible to get certain kinds of code correct in C, for instance, string parsing. Complete hyperbole. Nothing stops you from using a safe string library in C. > Also until pretty recently, C and C++ did not have a sane memory model Technically true, but in practice it was rarely relevant.
    • johncolanduoni 10y ago
      Lockless structures is one of those rare cases where it is relevant. Not that I think Java is great for these (Java's atomics support is not great compared to C/C++ or even C#), but at least it's not the free-for-all that C/C++ used to enjoy.
    • PeCaN 10y ago
      > Complete hyperbole. Nothing stops you from using a safe string library in C. Nothing technically stops you, it's just really hard. When even djb has suffered a string-processing-related bug¹ you can't reasonably expect to get string processing right all the time. Everyone thinks they can safely handle strings in C. It's like programmer chunibyo² or something. -- ¹ http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864 ² “8th-grader syndrome”; the sort of overly high opinions middle schoolers have of themselves
  • TickleSteve 10y ago
    Complete rubbish.... Do you really want a list of string-heavy s/w thats developed in C/C++ and in very widespread use? Should I start with: - Most interpreted languages... - Web servers....
• sandisk5 10y ago
  Because performance isn't the only requirement and Java is fast enough. Correctness, maintenance, extensibility, developer productivity, tooling, deployment, and recruiting are all also important.
• duaneb 10y ago
  Maybe the bottleneck is I/O (memory or external), not CPU.
• microcolonel 10y ago
  Correctness can be very difficult in Assembler, Fortran, and C; and consider the complexity of the systems they're implementing. Though a lot of it probably has to do with hiring. They could probably do a lot better with, say, OCaml or Rust. Jane Street uses OCaml for, presumably, this reason.
  • PeCaN 10y ago
    Jane Street isn't an HFT firm, though I do agree that OCaml would be a much better language than Java (though the lack of manual GC tuning could be a dealbreaker).
• stuffedBelly 10y ago
  Having written plenty of embedded system code myself, I wouldn't want to implement a full-blown application for HFT in C, not to mentioned Fortran or assembly (maybe a network/messaging layer in C/C++, which is very common). Performance is critical but it's not the only major factor, especially when it comes to trading, in which the complexity of the application can quickly grow daunting.
  • narrator 10y ago
    Bugs in HFT code can lose a lot of money very quickly too, so I'd imagine that Java code being less bug prone than C or assembly is also a consideration.
    • PeCaN 10y ago
      Or crashing, for that matter. If your C HFT program crashes, someone is on the hook for tens of thousands, minimum. (Not saying Java doesn't crash, but it's a bit more rare and gives you more opportunity to not lose $$$.)
• mavelikara 10y ago
  Here are my impressions from having worked as a programer on an HFT system during 2009-2011. When an HFT system makes money, some other person or system is loosing money i.e. it is a zero-sum game. And that person isn't going to sit idle; they are going to analyze their mistake and up their game. The industry parlance for this is, I think, that the "strategy dissipates into the market". This causes HFT systems to be always in active development. Spotting a strategy and putting together a system to take advantage of it, and spotting where your system is losing money and fixing it - both these need to be done with quick turn around time. Most strategies can be thought of as picking up nickels from in front of a on-coming train. Your best case "win" is a tiny amount of money; but your worst case "loss" is much much more money. The trick in HFT - the HF part - is to make these tiny wins over and over. But much actual money is involved, with very bad consequences should the program run into inopportune bugs. All of these - constant development, time to market pressure, high reliability - give the impression that Java is a better language to code this HFT systems in than C or Fortran.
  • TickleSteve 10y ago
    You seem to be saying that C & Fortran aren't a) Fast b) suitable for developing strategies. ...Now I've never used Fortran myself.... but none of those arguments seem to stack up.
    • peterashford 10y ago
      I think he's saying that reasonably fast code can be written reasonably fast in java. Writing fast C code is perhaps a more specialised task?
      • vanderZwan 10y ago
        But I thought HFT required unreasonably fast code?
        • taneq 10y ago
          But it requires it in an unreasonably short amount of time. Hence the tradeoff.
• yummyfajitas 10y ago
  Garbage collection. A common pattern in Java based systems is fan-out based processing. One immutable message is created, sent to multiple processors, who then combine signals to make a decision. Tracking the memory here would slow you down. But usually the JVM handles this just fine, and kills those objects in first generation. Also, Java has a fantastic standard library, probably the best concurrency system, and the JIT can actually make code faster than C++. It doesn't work for extreme low latency people - those guys write custom code for FPGA - but there is a healthy chunk of HFT for whom Java is a great choice.
  • easytiger 10y ago
    > and the JIT can actually make code faster than C++. How? Demonstrate with real examples
    • lucozade 10y ago
      > the JIT can actually make code faster than C++ > How? A JIT compiler can sometimes beat an AOT compiler because it has more information. For example, it is entirely feasible for a JIT to heavily optimise a fast path even if the optimised code wouldn't be correct for all cases that the source could be called for. If the JIT detects an uncommon case it can just fall back to the interpreted code. An AOT compiler will forego optimisations if it can't be sure that it will produce correct code. For example, C++ was generally considered slower than Fortran until restrict was added as the compiler had to be more conservative. However, restrict is, well, restrictive. Conceptually, a JIT could work around this if it had a function that didn't have restrict arguments but was usually called on distinct memory. It could hold an optimised path that assumed restrict but fall back if it detected otherwise. Now, some of this benefit can be had in an AOT compiler with profile guided optimisations. But usually, the AOT compiler will still tend to the conservative to balance aggression with code bloat.
      • gpderetta 10y ago
        It principle yes, but in practice? You see a trend with interpreted, then JITed languages eventually getting an AOT compiler, but I can't recall any natively compiled language getting a JIT for performance reasons (LLVM was supposed to allow that, but the JIT hasn't seen much love)
• zvrba 10y ago
  You can easily hot-swap classes in a running program as long as their interface doesn't change. I.e., you can tune your algorithm w/o restarting the server. I went wow the first time I edited a program during a debugging session and Eclipse just recompiled the class and reloaded it into the program. Yes, there details of getting this right (transferring the state), but nevertheless.. It'd be one heck of a job implementing this _correctly_ in a MT scenario for C and C++. JVM just does "magic" here.
  • ktRolster 10y ago
    It'd be one heck of a job implementing this _correctly_ in a MT scenario for C and C++. I think every major debugger can do this for C and C++ now
    • peterashford 10y ago
      Does that mean you can do it with live production code?
  • dalailambda 10y ago
    Doing this with dynamic libs in C/C++ is done frequently in some areas.
    • sievebrain 10y ago
      Yeah but your program has to be written to do it that way from the start, with a plugin boundary and so on. The JVM can do it for any code, with limitations, but there's a "DCE VM" that is a patched HotSpot. It can do far more kinds of hotswapping.
• nvarsj 10y ago
  Because not everything needs to be ultra fast. Only the pieces that need to respond quickly to market changes. The vast majority of logic in an HFT isn't this, it's business logic around determining parameters, and so on.