Date: Mon, 3 Oct 2022 15:44:39 +0000
I obviously can’t talk specifics, but in the industry in general I believe the following holds:
Timescales: When they matter, they matter absolutely. The industry is already working on pico-second accuracy measurements.
Nature of deadline: It’s not so much that faster is always better (it may for instance be too expensive to achieve). What matters is that you’re not slower than the next computer in line. As long as you’re faster than the others, you’re fast enough (until they speed up).
The cost of being too slow is simply loss of money. Whether it’s not making a profit you could have made (opportunity cost), or an outright loss.
Topology of the Hot Path: These vary greatly between implementations. There are single-threaded hot loops. There are multi-threaded event-reactive poll loops. One commont feature is that the hot path (whatever it is) will likely have a iminimum of mode switching between user and kernal space.
I/O: Typically the input and output of the hot path are discreet network messages. The protocol of those messages may vary. Line speeds can be several hundred Gbps.
Concurrency: Interthread / Interprocess communication is typically via shared-memory event queues. Implementations of those vary enormously across the industry, and can be truly esoteric.
From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Timur Doumler via SG14
Sent: Monday, 03 October, 2022 11:24
To: Patrice Roy via SG14 <sg14_at_[hidden]g>
Cc: Timur Doumler <cpp_at_[hidden]>
Subject: [SG14] Properties of HFT compared to other low-latency use cases
Hi SG14,
For a presentation this Thursday, I am currently comparing different use cases of low-latency programming, in particular video games, audio processing, and high frequency trading, and specifically the properties of the low-latency "hot path" for these use cases. I don't know much about HFT, so perhaps some experts here could answer a few questions? It would be immensely helpful.
- Typical time scales. In gaming, the deadline is typically one frame (~ 16 ms with 60 fps). In audio, it's typically the length of an audio buffer (~ 1–5 ms depending on the audio settings). Is it correct that HFT deals with much shorter timescales, i.e. you care about microseconds and even nanoseconds? What's the typical timescale?
- Nature of deadline. In audio and gaming, as long as you meet the deadline to generate one video frame/audio buffer, you're good, for example it typically doesn't matter if something takes 1.0 ms or 1.1 ms, as long as it *never* takes more than that. Is it correct that in HFT, it *does* matter? There's not so much a hard deadline, but more like the faster, the better, and reducing the operation by another microsecond is always desirable?
- What happens if deadline is not met. In audio, you get an audible glitch, which is very bad. In video games, you drop a frame, which is sometimes noticeable and not desirable. What about HFT? What's the typical cost of being too slow?
- "Topology" of the hot path. In audio, the "hot path" is a callback (controlled by the sound card + driver + OS kernel) coming in regular time intervals on a single dedicated audio processing thread. In video games, the "hot path" can be multiple threads, all dedicated to rendering. What about HFT? Is the hot path on a single thread? On multiple threads? Who calls this thread, how often, and under what circumstances? Is the hot path being called in regular intervals or following some kind of external event?
- What is the input and output of the hot path? In audio, the input is typically audio data or maybe MIDI data, and the output is more audio data. In video games, the input for the hot path the current state of the world, and the output is video frames. What is typically the input and output of the hot path in HFT?
- Concurrency. How does the hot path typically exchange data with other threads and the rest of the program? Atomics? Lock-free data structures? Something else?
I'd be very grateful for any insights you can give me!
Thanks,
Timur
P.S. I deliberately excluded embedded for now because it's such a diverse field that it's impossible to characterise as a whole: you have superloops, interrupt-driven flows, real-time operating systems and much more...
________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Timescales: When they matter, they matter absolutely. The industry is already working on pico-second accuracy measurements.
Nature of deadline: It’s not so much that faster is always better (it may for instance be too expensive to achieve). What matters is that you’re not slower than the next computer in line. As long as you’re faster than the others, you’re fast enough (until they speed up).
The cost of being too slow is simply loss of money. Whether it’s not making a profit you could have made (opportunity cost), or an outright loss.
Topology of the Hot Path: These vary greatly between implementations. There are single-threaded hot loops. There are multi-threaded event-reactive poll loops. One commont feature is that the hot path (whatever it is) will likely have a iminimum of mode switching between user and kernal space.
I/O: Typically the input and output of the hot path are discreet network messages. The protocol of those messages may vary. Line speeds can be several hundred Gbps.
Concurrency: Interthread / Interprocess communication is typically via shared-memory event queues. Implementations of those vary enormously across the industry, and can be truly esoteric.
From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Timur Doumler via SG14
Sent: Monday, 03 October, 2022 11:24
To: Patrice Roy via SG14 <sg14_at_[hidden]g>
Cc: Timur Doumler <cpp_at_[hidden]>
Subject: [SG14] Properties of HFT compared to other low-latency use cases
Hi SG14,
For a presentation this Thursday, I am currently comparing different use cases of low-latency programming, in particular video games, audio processing, and high frequency trading, and specifically the properties of the low-latency "hot path" for these use cases. I don't know much about HFT, so perhaps some experts here could answer a few questions? It would be immensely helpful.
- Typical time scales. In gaming, the deadline is typically one frame (~ 16 ms with 60 fps). In audio, it's typically the length of an audio buffer (~ 1–5 ms depending on the audio settings). Is it correct that HFT deals with much shorter timescales, i.e. you care about microseconds and even nanoseconds? What's the typical timescale?
- Nature of deadline. In audio and gaming, as long as you meet the deadline to generate one video frame/audio buffer, you're good, for example it typically doesn't matter if something takes 1.0 ms or 1.1 ms, as long as it *never* takes more than that. Is it correct that in HFT, it *does* matter? There's not so much a hard deadline, but more like the faster, the better, and reducing the operation by another microsecond is always desirable?
- What happens if deadline is not met. In audio, you get an audible glitch, which is very bad. In video games, you drop a frame, which is sometimes noticeable and not desirable. What about HFT? What's the typical cost of being too slow?
- "Topology" of the hot path. In audio, the "hot path" is a callback (controlled by the sound card + driver + OS kernel) coming in regular time intervals on a single dedicated audio processing thread. In video games, the "hot path" can be multiple threads, all dedicated to rendering. What about HFT? Is the hot path on a single thread? On multiple threads? Who calls this thread, how often, and under what circumstances? Is the hot path being called in regular intervals or following some kind of external event?
- What is the input and output of the hot path? In audio, the input is typically audio data or maybe MIDI data, and the output is more audio data. In video games, the input for the hot path the current state of the world, and the output is video frames. What is typically the input and output of the hot path in HFT?
- Concurrency. How does the hot path typically exchange data with other threads and the rest of the program? Atomics? Lock-free data structures? Something else?
I'd be very grateful for any insights you can give me!
Thanks,
Timur
P.S. I deliberately excluded embedded for now because it's such a diverse field that it's impossible to characterise as a whole: you have superloops, interrupt-driven flows, real-time operating systems and much more...
________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Received on 2022-10-03 15:44:48