Visit cppcon.org for details on next year's conference. CppCon sponsors have made it possible to record and freely distribute over 1000 sessions from the first CppCon in 2014 to the present. We hope you enjoy them!
Already love the first example. I wrote a performance/frame timer func, and obviously that *needs* to be as performant as possible so as not to burden the rest of... well, everything. Initially, I used Chrono. Too slow. Then I switched to filetime, which was much faster. But it still soaked up like 5% of my spent CPU, so, why? Well I checked out the ASM and saw that for some reason it was performing two [load effective], [copy]'s. I then realized, it's because I'm using both halves of the ULI I made to extract the full accuracy quadpart. I checked and, the low part works fine for comparisons for up to around 450s. A frame is 16.667ms or below. I dropped the upper part of the ULI along with the quadpart line, and the function was 50% faster. Don't trust the gut, trust the ASM and benchmarking.
That filter bug is actually easy to fix, just test the filter in the cached begin before returning it, if it fails, start at the real begin. Also, if the container is modified before the cached begin, isn't it also an undefined behavior?
Now its 2024 and we still might not see this in C++26 it is a shame how slow C++ develops in all things that are not template/type system crazy features
13:58 There is a slight (or big?) difference between "if (std::is_constant_evaluated())" and "if consteval". The former is a *runtime* check for whether it is being evaluated at compile time BUT also allowed in places where one expects a constant result. While the later is a compile time check. Both have different usecases, and neither substitute the other. One can do "int arr[std::is_constant_evaluated() ? 10 : 15]" but cannot do so with "if consteval". One can call consteval functions from inside "if consteval", but cannot from inside "if (std::is_constant_evaluated())" since the check is at runtime.
Can't wait for Carbon Lang enough 😓😪 (Rust is pretty fabulous).... I do understand all arguments and the perceived dip in care/quality of code from newer generation programmers however I guess C++ will continue to remain like this for reasons best known to the maintainers. C++ will have its use cases. New projects should simply use Rust and stop fighting C++.
For the last question: the CPU store buffer and register renaming makes it possible to hide results of operations from external observers (i.e. other cores or memory for instance). The changes are only made visible when they will be program-correct (i.e. the CPU will actually execute and go past the array bounds, but before actually "publishing" the changes it will check if the branch prediction was correct and discard the incorrect results, that's why anything works)
cmov is used for cases where the condition is close to random 50/50, since branching performs absolutely horrible there. In the presentation, random numbers generated for the test are in range 0-intmax (roughly 2 billion), while clamp limit is at 255, so the probability of mispredict is ~1.18e-7, which is why cmov is slower in the example.
