The overhead of FFI is rarely just about the instruction count of the call itself; it's about the erosion of determinism.
In my previous work building high-frequency bridges on Windows (MT4 context), we found that by strictly adhering to Modern C++ paradigms and RAII, the system’s "steady state" becomes a natural emergence of the logic itself, rather than something that needs to be manually forced. We saw the working set precisely lock at 11.0MB after 7 days of continuous operation, without any external memory trimming.
This is why, in my current rewrite of QuantNexus using Modern C++, I am explicitly avoiding managed runtime boundaries. Even with optimized FFI, the guest runtime's inability to respect L3 cache residency during context switches introduces a jitter that defeats the purpose of a zero-cost abstraction. I’m curious if the author has benchmarked the P99.9 tail latency of this new Java approach under heavy heap pressure, where the GC and the FFI layer inevitably start to collide.
The overhead of FFI is rarely just about the instruction count of the call itself; it's about the erosion of determinism.
In my previous work building high-frequency bridges on Windows (MT4 context), we found that by strictly adhering to Modern C++ paradigms and RAII, the system’s "steady state" becomes a natural emergence of the logic itself, rather than something that needs to be manually forced. We saw the working set precisely lock at 11.0MB after 7 days of continuous operation, without any external memory trimming.
This is why, in my current rewrite of QuantNexus using Modern C++, I am explicitly avoiding managed runtime boundaries. Even with optimized FFI, the guest runtime's inability to respect L3 cache residency during context switches introduces a jitter that defeats the purpose of a zero-cost abstraction. I’m curious if the author has benchmarked the P99.9 tail latency of this new Java approach under heavy heap pressure, where the GC and the FFI layer inevitably start to collide.