> Don't forget that most actual production renderers are multiple decades old. I use V-Ray, and the memory bandwidth is one of the defining factors of my rende

> Don't forget that most actual production renderers are multiple decades old. I use V-Ray, and the memory bandwidth is one of the defining factors of my rendering speed. I saw a noticeable bump when I went from DDR4-1866 to DDR4-2666. > L3 cache typically has bandwidth in the same order of magnitude as memory, while Intel is claiming to increase that by 3x in the article. My 500 GB/s number was the estimated L2 bandwidth for a Ryzen CPU. > Most renderers hop around him memory to trace rays through acceleration structures There's an Intel library called Embree which is very cache friendly. It's used by v-Ray, the raytracer that I use. https://www.embree.org/ https://www.embree.org/ > Yes, those exist, but they don't have anything to do with the article or cache sizes. When I had to implement a C++ convolution algorithm, it was pretty slow at first. Then I used V-Tune and Amplify to re-order the loops, optimize memory access patterns, and identify places where AVX or SSE intrinsics would be helpful. After doing that, I could then measure with Amplify that my convolution loop is now limited in performance by cache misses, meaning exactly what a larger cache would improve. And if I remember correctly, I got only 10% pipeline utilization, which would suggest that it could be 10x faster with fast enough memory.