作业七的性能瓶颈是随机数生成

[仙人独往来]

随机数生成重复构造随机数生成器
耗费了大量的CPU时间

This post has received 2 votes up.

[zyk]

我是使用libuv的线程池+work队列来实现多线程的，比如渲染一张128*128图，我就创建128*128个任务加到任务队列中，然后开启libuv的runloop通过线程池去执行。（我用的是4线程的CPU，线程池中线程数设置为4）

昨晚将随机数生成做成局部static的thread_local变量，这样会针对线程池中的每个线程创建一个随机数生成器，而不是每次调用随机数去构建生成器。

结论：这样做确实大幅提高了渲染效率，4线程的普通PC，渲染一张1024*1024、spp为2048的图，只需要一个多小时！

请问你是怎么测出性能热点在构建随机数生成器的？C++有什么厉害的性能分析工具吗？
这块我不是很熟悉，没做过类似的分析，谢谢！

This post has received 1 vote up.

[仙人独往来]

Visual Studio自带一个性能分析器，可以给出调用关系和时间。
并行粒度越大，享受到的加速效果越好，你可以考虑让4个线程独自渲染最后平均。
在我6核的i5-9400上使用5个线程（6线程因为抢占时间反而更慢？）在轮盘赌概论0.7的时候达到1024*1024*2000SPP的折算时间是20多分钟的样子。
遍历BHV树调用极多，如果你在其中使用了std::max(min)的话，考虑手工改写成分支（甚至改写成位运算消除分支<我并没有尝试>）也可以改进一些效率，考虑在字节点保存父节点指针来避免递归调用（我同样没有尝试）应该还可以进一步提速。
如果你对提升效率感兴趣的话，不妨试试这些建议。

[decay]

太感谢了，最早在实现多线程之前想要profile一下整个程序，优化的同时正好复习一下最近学的csapp第五章的知识，但无奈mac上用gprof和谷歌的profiler会有很多问题，与之搏斗了一天以后作罢。。按照你的发现修改了程序以后64spp渲染只需要40+秒，以前需要20分钟，尤其是我最近在微表面提高题那里疯狂踩坑，每次微调一下公式想看效果就得等上半小时左右，现在感觉写起bug来也有劲了！
另外由于我不是特别了解多线程的基本知识，只是用openmp调包实现了个简单的多线程，想问一下我把get_random_float中的random_device、梅森旋转引擎和均匀采样分布生成器都只是简单地设为static，这样在多线程上是不是会产生问题，如果是的话，这样的问题会对随机数的质量产生影响吗，因为我看最终的效果并没有什么偏差。
总之，十分感谢题主！！

This post has received 1 vote up.

[WWWWWWuuuuuu]

赞一个，随机数生成改成静态的，确实快了很多

[Author]

Posts