I made it FASTER // Code Review
Why Stack Overflow recommends it
Stack Overflow users link it as the origin of the std::accumulate versus plain loop performance question, where copying the optional result inside std::accumulate was a hotspot.
Recommended by 0 people across 0 different months, 2021 to 2023.
What it is
A 38-minute episode of The Cherno's Code Review series in which he reviews a viewer's C++ ray tracer built from Ray Tracing in One Weekend. He finds why it renders slowly, covering unique_ptr-wrapped arrays and the multithreading, then sets out to speed it up.
What people said
Cites auhmaan · 2021-12 · Stack Overflow · on “std::accumulate vs for loop, raytracing application”
This question is based on this video on YouTube [this video] made with the purpose of reviewing this project [LINK] . In the video, the host is analyzing the project and found out that the following block of code is a cause of performance issues: std::optional<HitRecord> HittableObjectList::Hit(const Ray &r, float t_min, float t_max) const { float closest_so_far = t_max; return std::accumulate(begin(objects), end(objects), std::optional<HitRecord>{}, [&](const auto &temp_value, const auto &object) { if(auto temp_hit = object -> Hit(r, t_min, closest_so_far); temp_hit) { closest_so_far = temp_hit.value().t; return temp_hit; } return temp_value; }); } I would assume that the std::accumulate functio
Cites StoryTeller - Unslander Monica · 2023-01 · Stack Overflow · on “Why do the new ranges remove_* algorithms move the first iterator?”
Very probably. They predate move semantics, and I know for a fact they weren't all reviewed for possible improvements. You can see a particularly interesting anecdote of it here [this video] (and the algorithm in question [LINK] *was* updated in c++20).
Cites Marek R · 2023-05 · Stack Overflow · on “AddressSanitizer: stack-buffer-overflow on boost cpp_int”
I've seen somewhere that std::accumulate has some strange problems. When I get rid of it from your code and used ranged based for loop everything works: int main() { size_t shift = 0; auto i = BigInt{}; for(auto it : b) { auto byte = BigInt{it}; i = i | (byte << shift); shift += CHAR_BIT; } std::cout << "Boost integer " << i << std::endl; } [LINK] I do not know why this happens. Didn't investigate how and when I've seen other cases of std::accumulate failure. I suspect that std::accumulate is causing some extra work to be done, which exposes some bug in boost::multiprecision::cpp_int . This extra work causing performance issue in other case I've seen std::acumulate had a problem [this video] with