6 ms·
London has an amazing Java community. They organise a lot of interesting talks!
by matant 8y ago
London has an amazing Java community. They organise a lot of interesting talks!
- tikkabhuna 8y ago100%. I've been going to their meetups for a few years now. If there's anyone in London who is interested in Java, give it a go. The meetups have a variety of topics, covering many skill levels. You can go sit at the back and slink off if you want, or sometimes they have pizza/beer and you can chat afterwards.
- kitd 8y agoThey have a large pool of developers working in HFT etc, which has a history of using Java.
- deleted 8y ago[deleted]
- piokoch 8y agoThat always amazed me. Why people keep torturing themselves applying Java to the usecase where Java is clearly not a right technology. I've watched very interesting talk by LMAX people and half of it was about how to overcome garbage collection gaps, latency, etc.
- geekus_maximus 8y agoIntegration. At some level the code has to integrate with other systems and in banks they tend to be Java systems.
- misja 8y agoThe answer: development time and runtime safety. You don't want your HFT system to blow up with a seg fault when the stock exchange is crashing.
- anonymousDan 8y agoHow would you weigh the two against each other in terms of importance? Could something like Rust be used to avoid the latter?
- bluGill 8y agoThe most important factor is how well can your language be optimized. HFT is about winner takes all. If the rust optimizer is even slightly worse than your competitors language you will make nothing. Development speed might get your a faster algorithm for a few weeks but your competition will notice you making that money and will catch up despite the slower pace of development and then their faster language will make the difference and you lose all future trades.
- steveklabnik 8y agoWe use LLVM, so we have the same optimizer as clang.
- bluGill 8y agollvm is not known as the best optimizer though. (but benchmarks tend to lie and llvm is always pretty close). There are also subtle areas where the front end can generate code that the backend cannot optimizer as well (though given equal effort I'd expect this advantage to go to newer languages that are design for modern optimizers - but effort is not equal with C++ getting for more love)
- steveklabnik 8y agoYes, my point is mostly informative; we get benefits from using their optimizer, and all the time and resources others pour in, so it's not solely about what the Rust team does. Your point about front-end optimizations is true though; we generally try to copy what clang does, but there's stuff we can do better as well. And also implementing some of our own front-end optimizations.
- dmos62 8y agoI've researched this some a few months back. I don't blame you for saying that Java is wrong for HFT. My first reaction was the same, but there's much more to it. Java has a few things going for it in HFT. The obvious pluses are it's mature and memory safe. What's less obvious is that you can make it low-latency. It takes a lot of work, but it's doable, at which point you have all the nice things: mature ecosystem, speed, latency, safety. It takes a lot of work, because Java was always oriented towards server use cases, as in high-throughput, not low-latency. That's changing by the way, there are two new GC engines coming out that are low-latency oriented. Also, there's been third-party JVMs with low-latency guarantees for quite a while. Of course, what's between the lines is that there isn't any easy answers for HFT people. You either choose mature safety and do gc gymnastics (because everything is throughput oriented), or you choose manual memory management, which is its own gymnastics. Anyway, that's my take. I welcome input and contradictions.
- bluGill 8y agoMostly I agree, but there is one factor that makes C++ (or any native compiled language) better than java for HFT: the ability to lie to the optimizer about what the hot path is. in HFT you have thousands of no trades for every trade, so the java optimizer will optimize the no-trade code path as more likely, then when the trade happens java pays a CPU branch prediction miss penalty at the only time low latency matters. You have to have good algorithms optimized to the max for this to matter though.
- dmos62 8y agoThat's interesting, never thought about that.
- bluGill 8y agoUnless you write HFT code, or follow talks by those writing HFT code you probably wouldn't. When you write HFT code you have to look at profiles and think about cache misses until branch missed become something to consider. If you don't come up with that idea someone else will and they will beat you to every trade and put you out of business.
- scott00 8y agoOne important thing to know is that allocating memory in C or C++ has high and/or unpredictable latency relative to the target latency of HFT code. So for critical paths, you end up needing to do the same kind of pre-allocation tricks in C/C++ that you would need to do in Java. There is some benefit to being able to write more natural code in the non-critical paths, but that has to be weighed against the overall development advantages that lead people to choose Java over C/C++ in other industries.
- twic 8y agoC and C++ (and Rust!) can put objects on the stack, so you have a lot more leeway to write normal idiomatic code without hitting the allocator. When Java gets value objects, this sort of work will begin to get a lot easier in Java as well, but there will be a lot of catching-up to do.
- deleted 8y ago[deleted]
- scott00 8y agoA very good point. Most of my GC whispering is done in .NET, which also has value types, but I was guessing that escape analysis in Java would solve most of the problems in this regard. Is that not actually the case?
- ynniv 8y agoIn trading, correctness is still a lot more important than latency. Using Java instead is about risk avoidance, which is why you also see people using OCaml.
- SanderMak 8y agoI'll be speaking there January next year and definitely looking forward to that! Heard great things about LJC.