ฝัง
- เผยแพร่เมื่อ 25 ก.ค. 2024
- www.cppnow.org
/ cppnow
---
What is Low Latency Cpp? (Part 2) - Timur Doumler - CppNow 2023
Slides: github.com/boostcon
---
It is often said that C++ is a great language for low latency systems, such as finance, audio processing, and video games. But what exactly do we mean by "low latency"? How is that different from "high performance"? And what makes C++ a great language for that? This talk is an attempt at answering these questions. We will look at low latency use cases across these different industries, establish their commonalities and differences, and discuss typical challenges in low latency systems and C++ techniques to overcome them.
---
Timur Doumler
Timur Doumler is the Developer Advocate for C++ tools at JetBrains and co-host of CppCast. He is an active member of the ISO C++ standard committee, where he is currently co-chair of the Contracts study group. As a developer, he worked many years in the audio and music technology industry and co-founded the music tech startup Cradle. Timur is passionate about clean code, good tools, low latency, and the evolution of the C++ language.
---
Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
TH-cam Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org
/ cppnow
---
#boost #cpp #latency - วิทยาศาสตร์และเทคโนโลยี
Thanks for the talk, it was very interesting!
Glad to hear that this presentation was helpful!
11:03 on Intel platforms there are also specific instructions and mechanisms for cache interactions, such as prefetch, demote, and bypassing cache. Theres’s also CAT - “cache allocation technology” that can be used to design what the caches can or cannot hold
Very entertaining talk!
Timur, about double buffering and SeqLock, there is other way. I work in HFT, and we use it for some monitoring of big values. It is called Chen Algorithm, or Tripple buffering. It makes writer wait free, and read wait free. If there is only one reader, it is very simple code. With more readers it gets more complicated (and writer overheads scales with number of readers, but with one reader it is easy), but also doable. For multiple readers, we just take a lock, so only one reader actually reads.
Is the idea that you have one buffer for the writer and then two buffers per reader? So if you have one writer thread and three reader threads, you can use seven buffers for a wait-free sync?
48:00 there is some name shadowing for `new_coeffs` within `update_coeffs()`. I believe all but one on the first line should be something else, e.g. `new_storage`. Otherwise, thank you for this excellent talk!
7:21 Sergey Slotin’s cppcon talk where such techniques are discussed: th-cam.com/video/1RIPMQQRBWk/w-d-xo.html
I would have expected some chapter talking about what operating systems have to offer to allow for deadline-constraint realtime to be met.
For HFT, ideally, there'd be no OS at all. For a space shuttle OS with "hard real time" requirements, it's less about getting the lowest latency and more about making sure the OS is always running predictably at the worst case. So if you have a theoretical main loop that calls "OS_UpdateState(os_state)" to update the entire OS state on each loop, what you want is for that call's timings to be consistent regardless of what data you give it or what resources you create/delete that tick.
55:53 [slide 132] I believe that the find() method is missing “while (p && p->t != t)” right before “p = p->next;”
Yes, this find() will just get head->next. Further, I think _front suffix can go from pop/push because it is implicit from the thing being a stack. Also push_front is making an extra copy as it takes input by value.
Great presentation! At timestamp 48:52, do we not have a race condition in the case of concurrent updaters?
Yes. I believe this code only supports a single updater thread (the fact that storage isn't atomic/synchronized in any way is an indication).
I guess if there are multiple update threads and all of them aren't "hot", they can synchronize amongst themselves using a mutex
Yes, this can only work with a single producer because `storage` is not atomic. I also noticed a missing `)` of the for loop in `update_coeffs()`, which makes it a bit confusing to read.
Undefined behaviour should have been SG13 ...
bad sound again. every cough in the audience, weird clicks and scratches, timur echoing : (
Can't have a talk related to quality audio processing without crappy sound.