在专业的环境中，我可能不会对依赖编译器的良好意愿感到有信心。通过"；nmmintrin.h&34；、__m128、_mm_set_ps、_mm_add_ps和_mm_div_ps[5]使用内部函数会更安全。然而，出于研究目的，这是可以接受的。修改向量结构以操作四个项(b.cpp)来保护数据包、SIMD指令、MULPS和ADPS。$clang-lm-ofast-o b b.cpp$time./b 17>；/dev/null实际0m59.722suser 0m59.719ssys 0m0.000s。
在这一点上，是时候使用Ryzen 52600上的其他11个内核了。上一练习中的代码大大简化了这项任务。几个pthreadcreate和pthreadjoin产生了c.cpp，这会产生540个线程，每个线程呈现960像素的行。$clang-lm-lpthread-ofast-o c c.cpp$time./c 128>；/dev/null实际0m55.203suser 10m52.188ssys 0m0.063s。
正如预期的那样，性能收益与内核数量呈线性关系。他们中的12人被允许将抽样推到128spp。然而，视觉效果太个性化了，我不喜欢。有一个可见的重复水平图案。这可以用截断libc的rand()[6]并只保留线性同余生成器(LCG)实现的随机生成器来解释吗？没有。LCG很好。问题是每个线程伪随机数生成器种子都是用相同的值初始化的。这意味着每行使用相同随机序列。更改种子值以使用线程ID修复了故障(d.cpp)。琐事：上周的业务raytracer优化引起了读者的反馈，他们建议500多个线程扰乱了调度器，可能会降低性能。我试图降低线程数(12、24，甚至36)，但无法确认此声明。操作系统可能无法处理10,000个线程，但看起来Linux能够很好地处理其中的500个线程。
用于名片光线跟踪器的所有优化都应用于e.cu。速度增长(2048spp)是惊人的。不幸的是，生成的图像也是如此。那个虫子花了一个下午才找到。最终，罪魁祸首被确定为快速数学旗帜，这使得固有的__POWF对于光线行进来说太不准确了。用手动乘法(f.cu)代替它解决了问题，但也将spp降低到600。还有一个问题。对于整个流式多处理器，使用相同的种子未初始化种子匆忙地转换了伪随机生成器。使用Curand并让每个块/线程有一个种子解决了这个问题(g.cu)。
从OptiX 5.0开始，NVIDIA提供基于人工智能的消噪器和预先训练好的神经网络。尽管NVIDIA声称这个模型是使用从1000个3D场景渲染的数万张图像进行训练的，但我对结果持保留态度。我甚至没有检查API，而是使用Declan Russeel的独立可执行文件[7]。消噪器运行了300毫秒，结果让我收回了我的话。它太棒了，太令人兴奋了。耗费1M渲染的去噪600spp相当于耗费1h渲染的40,960spp。下面是从1spp到2048spp的去噪版本(D)。存在去噪效果不佳的最小值(1spp和2spp：p)。相反，有一个门槛，超过这个门槛，回报就会减少。这种方法的最佳点似乎在512spp左右。*