CppCon 2016: Timur Doumler “Want fast C++? Know your hardware!"
Why Stack Overflow recommends it
Stack Overflow users link it when answering or asking about low-level performance, such as CPU cache behaviour and why hardware knowledge matters for fast code.
Recommended by 2 people across 2 different months, 2019 to 2022.
What it is
A CppCon 2016 talk by Timur Doumler, a JUCE senior engineer at ROLI, on how hardware properties affect C++ performance. It walks through code examples and benchmarks covering cache locality and associativity, false sharing, alignment, branch prediction, pipelining, denormals and SIMD.
What people said
Recommends Paul Belanger · 2019-07 · Stack Overflow · on “How to optimize a decision in a CFD C code”
Here's a good video that describes some of the things that happen on the low-level CPU side that you can exploit to make code run faster in some situations: [this video] Keep in mind though that optimizations like this should only be considered after you've done all the other stuff, like reducing the algorighmic complexity of your functions, etc.
Recommends Timo · 2019-08 · Stack Overflow · on “Is it thread-safe to access a Mat with multiple threads in OpenCV?”
Generally, parallel reading is not a problem as a cv::Mat is just a nice wrapper around an array, just like std::vector (yes there are differences but I don't see how they would affect the matter of the topic here so I'm going to ignore them). However parallelization doesn't automatically give you a performance boost. There are quite a few things to consider here: Creating a thread is ressource heavy and can have a large negative impact if the task is relatively short (in terms of computation time) so thread pooling has to be considered. If you write high performance code (no matter if multi- or single threaded) you should have a grasp of how your hardware works. In this case: memory and CPU
Cites D.J. Elkind · 2022-10 · Stack Overflow · on “Why I cant observe the effect of 4/8-way set associative cache in my test code”
I am trying to reproduce an experiment described here [this video] . The result should show the effect of 4/8-way set associative cache--when the step size is "just right", cache memory will be saturated easily, dragging down the performance a lot. The below is my test code: #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #include <string.h> int main() { srand(time(NULL)); const size_t arr_len = 256 * 1024 * 1024; uint32_t* arr = malloc(sizeof(uint32_t) * arr_len); for (size_t i = 0; i < arr_len; ++i) { arr[i] = rand(); } struct timespec ts; uint8_t sum = 0; double delta, t0; size_t idx; for (size_t step = 1; step < 2049; ++step) { timespec_get(&ts, TIME_UTC); t0 = ts