4 ms·
Fascinating application of the language and a terrific write-up. I would presume a GC language would normally be a disqualifying factor in real-time trading, bu
by infamousclyde 3y ago
Fascinating application of the language and a terrific write-up. I would presume a GC language would normally be a disqualifying factor in real-time trading, but I think I'm coughing up some premature optimization, especially with what looks like a pretty beefy rig. Congratulations though, this is spectacular.
- _zkyx 3y agoYeah, I never really looked a GC. Most of my trades take at least 500ms+ round trip. It's more in the latency to the broker and getting confirmations that I've been trying to tighten up. At least that's what I'm seeing right now.
- mhh__ 3y agoYou say this as if memory allocation in general isn't extremely slow.
- kasey_junk 3y agoFor trading systems that are still software based they absolutely do not allocate or reclaim on the hot path for this reason.
- infamousclyde 3y ago"That are still software based" is interesting. Are there hardware-based trading systems?
- kasey_junk 3y agoYes. The fastest systems are asic or fpga based. They typically never leave the router.
- infamousclyde 3y agoI guess my presumption was that algorithmic trading was a very tight feedback loop, with as many controlled variables (i.e., GC) as possible, so I think it just subverted some of my misplaced expectations.
- chollida1 3y agoNah, if you are retail and using Interactive brokers then you'll never notice teh GC pause at all. Mostly because you'll never be able to respond to each tick as by the time the tick gets to you the market has moved. Use the language that you know and can work with the fastest. For retail trading GC vs non GC will never matter at all.