5 ms·

If you're parsing market data then you shouldn't really be allocating at all once the initial setup is complete. So there shouldn't be a need for ref counts.

If you're parsing market data then you shouldn't really be allocating at all once the initial setup is complete. So there shouldn't be a need for ref counts. This is because the allocator itself can have an unbounded runtime that takes milliseconds, causing you to drop. In the past I've replaced malloc with an implementation that asserts if called on certain threads after init time.

tom_ 7y ago
Milliseconds??! What causes that to occur? Though I suppose if they can take that long, avoiding them is an even better idea than it is normally... For constant time allocations, try TLSF: http://www.gii.upv.es/tlsf/ http://www.gii.upv.es/tlsf/
- cogman10 7y ago
  I'm not the op, but I'm guessing large amounts of fragmented memory is what causes that. It's one benefit of a gced language with compaction, allocations are typically bounded (except when they trigger a gc).
  - CoolGuySteve 7y ago
    Except compaction can also take many milliseconds and come from different threads. Writing a trading system in Java is harder than C++ imo because where before you had an allocation problem, now you have a multithreaded randomly stalling allocation problem. Virtu did it but everything I’ve heard about it nullifies the benefits of using java in the first place.
    - cogman10 7y ago
      Newer Java GCs are very low latency (microsecond). You trade performance and memory for that low latency though. AFAIK, they are still compacting. Still though, probably makes sense to do it in a lower level language. It's just far easier in C++ to decide that "Hey, you know what, I just want a big memory block that I control". I've even heard of game devs doing things like having per frame allocators. They get super fast allocation because they just pointer bump and at the end they simply reset the pointer back to location 0. I'm sure trading systems could do something similar.
      - nwallin 7y ago
        The point is that a one millisecond pause is unacceptable. Low latency Java GCs have average latencies of one millisecond, 99th percentile latencies of 10 milliseconds, and 99.9th percentile latencies are neither measured nor optimized for. I don't consider it realistic to think that garbage collected languages might ever be usable in the context of game engines or HFT.
        cogman10 7y ago
        > game engines Game engines are already written in GCed languages. Java in particular. You may be right that a 10ms pause is unacceptable for HFT. However, for a FPS, 10ms is more than acceptable. It translates to 1 or 2 missed frames in the worst case. A bigger issue with using Java in particular for games is it's lack of value types. Writing high performance code for java is just that much harder because the language gets in the way.
        CoolGuySteve 7y ago
        The only serious engine I know of that's written in Java is Minecraft and its performance problems are notorious. Microsoft XNA and Unity's .net support were also pretty popular but the popular games written in those languages (like Bastion) didn't have many heavyweight assets or allocator pressure.
- ycombobreaker 7y ago
  Most likely it is simply invoking a syscall (sbrk or mmap), which invokes the scheduler and may yield the time slice. Feed parsing code may not issue any other syscalls (entirely userspace), turning the allocation into a bit of russian roulette.

tom_ 7y ago

Milliseconds??! What causes that to occur? Though I suppose if they can take that long, avoiding them is an even better idea than it is normally... For constant time allocations, try TLSF: http://www.gii.upv.es/tlsf/ http://www.gii.upv.es/tlsf/

cogman10 7y ago
I'm not the op, but I'm guessing large amounts of fragmented memory is what causes that. It's one benefit of a gced language with compaction, allocations are typically bounded (except when they trigger a gc).
- CoolGuySteve 7y ago
  Except compaction can also take many milliseconds and come from different threads. Writing a trading system in Java is harder than C++ imo because where before you had an allocation problem, now you have a multithreaded randomly stalling allocation problem. Virtu did it but everything I’ve heard about it nullifies the benefits of using java in the first place.
  - cogman10 7y ago
    Newer Java GCs are very low latency (microsecond). You trade performance and memory for that low latency though. AFAIK, they are still compacting. Still though, probably makes sense to do it in a lower level language. It's just far easier in C++ to decide that "Hey, you know what, I just want a big memory block that I control". I've even heard of game devs doing things like having per frame allocators. They get super fast allocation because they just pointer bump and at the end they simply reset the pointer back to location 0. I'm sure trading systems could do something similar.
    - nwallin 7y ago
      The point is that a one millisecond pause is unacceptable. Low latency Java GCs have average latencies of one millisecond, 99th percentile latencies of 10 milliseconds, and 99.9th percentile latencies are neither measured nor optimized for. I don't consider it realistic to think that garbage collected languages might ever be usable in the context of game engines or HFT.
      - cogman10 7y ago
        > game engines Game engines are already written in GCed languages. Java in particular. You may be right that a 10ms pause is unacceptable for HFT. However, for a FPS, 10ms is more than acceptable. It translates to 1 or 2 missed frames in the worst case. A bigger issue with using Java in particular for games is it's lack of value types. Writing high performance code for java is just that much harder because the language gets in the way.
        CoolGuySteve 7y ago
        The only serious engine I know of that's written in Java is Minecraft and its performance problems are notorious. Microsoft XNA and Unity's .net support were also pretty popular but the popular games written in those languages (like Bastion) didn't have many heavyweight assets or allocator pressure.
ycombobreaker 7y ago
Most likely it is simply invoking a syscall (sbrk or mmap), which invokes the scheduler and may yield the time slice. Feed parsing code may not issue any other syscalls (entirely userspace), turning the allocation into a bit of russian roulette.