9 ms·

Quite a few of the top HFT firms use Java, almost exclusively. The trick is to segment your critical path code (whatever is executing the actual trades and is

by nvarsj 11y ago

Quite a few of the top HFT firms use Java, almost exclusively. The trick is to segment your critical path code (whatever is executing the actual trades and is highly susceptible to delays) from any business logic. Then you can focus on making critical path components fast - disable GC completely, keep object allocations way down, audit every line of code, etc. With such a setup you can even do better than typical C++ because you avoid virtually all object allocation/deallocation costs that C++ has. Java object allocation is dirt cheap, it just hurts when you GC, which you can basically avoid or schedule for out of hours. If you want better I would not bother with C++ at all personally, but use C / assembly or even look at FPGA type setups.

jrcii 11y ago
I was going to say for people who are going to lengths like kernel bypass networking to get these trades out faster I wouldn't be surprised if the key stuff is in assembly.
- ryao 11y ago
  I would be. Manually written assembly is not necessary better than what a compiler would generate and with super scalar pipelined architectures, seemingly better assembly can turn out to execute in the same amount of time. The things that matter are algorithmic.
  - slededit 11y ago
    I think you assume compilers are doing more work than they actually are. Processor models in the compiler are generally fairly simplistic and even ICC can easily be beat by hand tuned assembly. Where compilers shine is allowing broad process-wide optimization.
viraptor 11y ago
This sounds like simulating arena allocation in Java by disabling GC temporarily. Except it's worse than arena allocator, because it's still mixed up in a general heap and costs more at collection. Not sure I buy the argument that this is cheaper than C++. After all, in C++ you could just drop the whole arena instead, so you get cheap alloc + super-cheap free.
- sievebrain 11y ago
  Collection cost in that model is irrelevant as it's only a split second and happens after hours. Yes, you can emulate a young generation in C++ or even multiple young gens (i.e. arenas), obviously, as you can do anything in C++ that you can do in Java and vice-versa (java has the Unsafe class that allows you to do low level programming with pointer arithmetic etc). The question is not, can it be done, but rather what's easier and lower cost? With the Java approach, the only developer overhead is making sure you don't do too much allocation on the hot path, then sizing your young gen to avoid collections (one command line flag), and doing a GC at night. Not nothing but not too hard either; after all, you can allocate if you really need to, and some allocations will be optimised out anyway. The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. Not that different, until you screw up and try to delete something on the stack or forget to delete something that isn't. That's when the robustness the GC is giving you starts to pay off.
  - sandGorgon 11y ago
    This is very interesting - is there any sample code one can learn from to build something in this style of programming ? Especially the deployment - do you have a scheduled that triggers GC or do you simply kill and restart, etc.
    - merb 11y ago
      Actually you can trick the JVM to run a Full GC. If you run: jmap -histo:live <PID> it will show a memory map of all the live objects and since java needs to run a full GC cycle to do that it will actually run a Full GC.
  - CyberDildonics 11y ago
    > The question is not, can it be done, but rather what's easier and lower cost? I thought it was about speed. > The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. The C++ equivalent would be to do heap allocation and never free, then shut the process down which will return its memory to the OS. Heap fragmentation wouldn't matter here since you aren't freeing any memory. Fundamentally if you can avoid freeing any memory all day then you should just allocate it up front an be done with it. Anything else is ignoring the more fundamental point that you are using a limited amount of memory and pretending that you aren't.
CyberDildonics 11y ago
> better than typical C++ because you avoid virtually all object allocation/deallocation costs that C++ has So to have Java perform better than C++ you just have to avoid allocation in Java and leave it in in C++? > If you want better I would not bother with C++ at all personally, but use C / assembly or even look at FPGA type setups. There is nothing in C that gives it a speed advantage over C++. Basically you've discovered step 1 of 3 when optimizing software (step 0 is to profile) - 1. Minimize heap allocations 2. Rework memory access for cache locality 3. Use SIMD 1 and 2 can be done with C++. 3 really needs to be done with something like ISPC so that SIMD use isn't fragile and compiler dependent.
na85 11y ago
If you're disabling GC, why use Java at all? That's the point of using Java (or any interpreted language), isn't it? Avoiding manual memory management? If you're going to go through all that horrid FactoryFactory Factory = new FactoryFactory(); bullshit, might as well get the benefits of the GC. And if you don't want the GC, why not write your code in something else?
- recursive 11y ago
  > If you're going to go through all that horrid FactoryFactory Factory = new FactoryFactory(); I get the impression that your only exposure to java is through jokes and blogs from dynamic typing evangelists.
  - nv-vn 11y ago
    How would that show any connection to dynamic typing? I imagine that the GP is coming from the perspective of C based on the fact that they're criticizing the use of garbage collection.
  - na85 11y ago
    You'd be incorrect.
  - deleted 11y ago
    [deleted]
- gravypod 11y ago
  If you give Java a try, it's got a lot more impact than Factory. Play around with the language a bit, there are things in the JVM and the language that really change the way you think about programming.
  - smac8 11y ago
    I'm a fan of Java in some senses, but curious to here what things you discovered in the language or JVM that changed how you thought about programming
thefastlane 11y ago
> Quite a few of the top HFT firms use Java, almost exclusively. such as whom?

by nvarsj 11y ago

jrcii 11y ago

I was going to say for people who are going to lengths like kernel bypass networking to get these trades out faster I wouldn't be surprised if the key stuff is in assembly.

ryao 11y ago
I would be. Manually written assembly is not necessary better than what a compiler would generate and with super scalar pipelined architectures, seemingly better assembly can turn out to execute in the same amount of time. The things that matter are algorithmic.
- slededit 11y ago
  I think you assume compilers are doing more work than they actually are. Processor models in the compiler are generally fairly simplistic and even ICC can easily be beat by hand tuned assembly. Where compilers shine is allowing broad process-wide optimization.

viraptor 11y ago

This sounds like simulating arena allocation in Java by disabling GC temporarily. Except it's worse than arena allocator, because it's still mixed up in a general heap and costs more at collection. Not sure I buy the argument that this is cheaper than C++. After all, in C++ you could just drop the whole arena instead, so you get cheap alloc + super-cheap free.

sievebrain 11y ago
Collection cost in that model is irrelevant as it's only a split second and happens after hours. Yes, you can emulate a young generation in C++ or even multiple young gens (i.e. arenas), obviously, as you can do anything in C++ that you can do in Java and vice-versa (java has the Unsafe class that allows you to do low level programming with pointer arithmetic etc). The question is not, can it be done, but rather what's easier and lower cost? With the Java approach, the only developer overhead is making sure you don't do too much allocation on the hot path, then sizing your young gen to avoid collections (one command line flag), and doing a GC at night. Not nothing but not too hard either; after all, you can allocate if you really need to, and some allocations will be optimised out anyway. The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. Not that different, until you screw up and try to delete something on the stack or forget to delete something that isn't. That's when the robustness the GC is giving you starts to pay off.
- sandGorgon 11y ago
  This is very interesting - is there any sample code one can learn from to build something in this style of programming ? Especially the deployment - do you have a scheduled that triggers GC or do you simply kill and restart, etc.
  - merb 11y ago
    Actually you can trick the JVM to run a Full GC. If you run: jmap -histo:live <PID> it will show a memory map of all the live objects and since java needs to run a full GC cycle to do that it will actually run a Full GC.
- CyberDildonics 11y ago
  > The question is not, can it be done, but rather what's easier and lower cost? I thought it was about speed. > The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. The C++ equivalent would be to do heap allocation and never free, then shut the process down which will return its memory to the OS. Heap fragmentation wouldn't matter here since you aren't freeing any memory. Fundamentally if you can avoid freeing any memory all day then you should just allocate it up front an be done with it. Anything else is ignoring the more fundamental point that you are using a limited amount of memory and pretending that you aren't.

CyberDildonics 11y ago

> better than typical C++ because you avoid virtually all object allocation/deallocation costs that C++ has So to have Java perform better than C++ you just have to avoid allocation in Java and leave it in in C++? > If you want better I would not bother with C++ at all personally, but use C / assembly or even look at FPGA type setups. There is nothing in C that gives it a speed advantage over C++. Basically you've discovered step 1 of 3 when optimizing software (step 0 is to profile) - 1. Minimize heap allocations 2. Rework memory access for cache locality 3. Use SIMD 1 and 2 can be done with C++. 3 really needs to be done with something like ISPC so that SIMD use isn't fragile and compiler dependent.

na85 11y ago

If you're disabling GC, why use Java at all? That's the point of using Java (or any interpreted language), isn't it? Avoiding manual memory management? If you're going to go through all that horrid FactoryFactory Factory = new FactoryFactory(); bullshit, might as well get the benefits of the GC. And if you don't want the GC, why not write your code in something else?

recursive 11y ago
> If you're going to go through all that horrid FactoryFactory Factory = new FactoryFactory(); I get the impression that your only exposure to java is through jokes and blogs from dynamic typing evangelists.
- nv-vn 11y ago
  How would that show any connection to dynamic typing? I imagine that the GP is coming from the perspective of C based on the fact that they're criticizing the use of garbage collection.
- na85 11y ago
  You'd be incorrect.
- deleted 11y ago
  [deleted]
gravypod 11y ago
If you give Java a try, it's got a lot more impact than Factory. Play around with the language a bit, there are things in the JVM and the language that really change the way you think about programming.
- smac8 11y ago
  I'm a fan of Java in some senses, but curious to here what things you discovered in the language or JVM that changed how you thought about programming

thefastlane 11y ago

> Quite a few of the top HFT firms use Java, almost exclusively. such as whom?