by definition, real-time does not equal to low-latency, although most of time people tend to use interchangeably. Real-time is a deterministic characteristic.
I suggest an additional (optional) parameter to the attribute: [[realtime_safe(n*m)]] void do_sth(int* array2d, int n, int m); In general attributes for runtime might be useful, which would allow more complex code analysis: [[average_time(n*std::log(n)), worst_time(n*n)]] void sort(...); I guess compilers could bubble up this attribute through callers, such that tools can show the runtime behavior of any function.
the best true random number generator ive seen is a reverse polarity base emitter junction in a bjt with non connected collector connected to an ADC...
This guy has an unwarranted phobia of multi-threading. What guarantees are there that his beloved single thread won't be interrupted and re-scheduled by the OS? None. I'd rather make my app faster with multi-threading and thus more "realtime".
> This guy has an unwarranted phobia of multi-threading. Where do you see this? > What guarantees are there that his beloved single thread won't be interrupted and re-scheduled by the OS? By setting the appropriate thread priority. > I'd rather make my app faster with multi-threading and thus more "realtime". Multi-threading and realtime-safety are orthogonal. You can use several threads for real-time audio computation (most DAWs do this), but the code for each thread still has to be real-time-safe.
If you have a real-time audio processing thread, there isn't a hard guarantee as such (because it's not a RTOS) but in practice it works really well as the thread gets a high priority assigned by the OS and therefore won't be rescheduled unless you miss the deadline
For hard realtime? Yes, that's the safer bet. It's not necessary because C++ is not all that unreliable in this regard, but to be honest... if you have a real hard real time problem... like making sure that that 100 ton crane really stops before something really heavy hits the ground really hard... yeah, stick to C. ;-)
Fantastic talk! The audio quality is great. Your talk has a constant level of abstraction, this makes it easy to follow and absorb. You mention where there are rabbit holes and give a summary of your findings, that's so efficient. Your slideware greatly supports your narrative, is short and precise. The overall narrative visits topic after topic, giving an overview, some examples, some details, some outlook (like inpace_function, static_vector) and mentions the standard or papers where useful. One of the best talks of CppCon 2021! I have nothing to do with audio but I enjoyed it beginning to end.
I find it sad that it's 2022 and Timur *still* has to dispel the "lambdas heap allocate" myth. Lambdas have been in the language for more than ten years at this point. How many CppCon talks pointing this out is it going to take before we can stop re-explaining all this?
I'm not sure why you'd want to enter a try block if you don't want to throw exceptions. Isn't the whole point of that structure to guard against exceptions?
In some scenarios, you don't care about real-time safety (or performance in general) in the case you end up on the sad path (exception is thrown, and you go down some error handling code) but you do care about it on the happy path (exception is not thrown but the try block is still there)
There were a lot of primitives from the thread support library getting tossed out. I wish there was a bit more time spent going over why. Having worked in an RTOS environment, posting semaphores or a msg to a queue seems like a common thing to do from a high priority thread.
technically you could do algorithms that are linear or worse in time complexity if you know that your input is within a given range for that the time complexity is within the deadline (or rather some percentage thereof)
You could do this to get a buffer of length computed at runtime before your thread goes real-time, but: • since its size would never change, you’d be better off with a std::unique_ptr stored alongside its size in a std::size_t since the vector has to additional data (like its capacity) which you wouldn’t need here; • you would still need the std::pmr::monotonic_buffer_resource. However, you couldn’t do it in a freestanding environment since dynamic allocations aren’t supported in those.
@ real time safe dynamic memory: pre-configured and pre-allocatable data structures capacity like string, containers (vectors, ...) etc. can be used. As often in real time programming this shifts work from runtime to compile time, so memory use measurements with a profiler gives information for the system memory capacity configuration, which is good to be also on the safe side.
49:10 are we seriously considering the possibility of rolling same INT_MAX value like a thousand times in a row? for it to be a noticeable performance hit
38:48 Is waking up a thread really a problem in practice? If you do multi-threaded DSP, you always have to synchronize threads. The helper threads typically wait on a semaphore and the "main" audio thread posts to the semaphore to wake them up. How would you do this if you were not allowed to wake up threads?
54:30 std::atomic itself might add memory fences or hardware locks depending on the std::memory_order. You can't have lock free data structures without these. Luckily, there is no reason why they shouldn't be real-time safe. They work on the CPU level, not on the OS scheduler level.
Fascinating talk, thank you for this. If applicable, and where the problem areas are 'small'/manageable, would writing those sections in assembly language give you your required predictive execution behaviour? Of course, it would help if kernel calls are not used, or if used, they don't re-introduce what you seek to prevent. We used to re-write specific (problematic) kernel routines in days gone by - mainly removing their general purpose nature for our specific use cases(and gaining significant speed and 100% behavioural predictability)...don't know how doable that is here/today. A damn shame if those days are gone. Today's abstraction is both good and bad (loss of control, predictability, etc)
Most important I think here is avoid using std containers ( or maybe with a custom preallocator ) , and anything else appart from atomic in multithreading . I did not know actually stdarray is allocated on the stack good info there .
This is a great talk, and covering a subject which I didn't manage to find many good resources about. Can you recommend other resources that cover this topic? Or is the standard the only place to look into?
Rule number one: you don't rely on the standard to "guarantee" a compiler property. You actually check whether YOUR compiler actually has that property when it compiles YOUR code.
operator new has A LOT of overloads (taking std::align_val_t, taking std::nothrow_t, etc). Do you handle all of them? Also, what happens if you work with a 3rd party class that overloads its own operator new? How do you guarantee that that never gets called?
alloca() doesn't compose, it can only be used in the body of the function where it's called, so for example you can't build a dynamic array class around it.
Why on earth would I use the STL in real-time scenarios. It's completely unsuitable (algorithms excluded) and figuring out whether I can use a piece from it takes me more time than rewriting it for real-time audio needs.
