多线程光线追踪程序：8线程与2线程性能无差异问题排查

1. 程序的性能瓶颈可能是什么？ #

• 任务粒度太小：每个像素单独创建线程，线程的创建、销毁及上下文切换开销远超过单像素计算耗时，操作系统调度成本剧增，直接抵消多线程并行的收益。
• BlockingQueue的锁竞争：如果自定义队列的同步实现（如std::mutex+std::condition_variable）未做优化，百万级任务的入队、出队操作会引发严重的锁争抢，线程大量时间消耗在等待锁上，而非执行计算。
• CPU缓存命中率低：尽管world是只读共享，但单像素计算时访问的场景数据（物体、材质）若在缓存中分布零散，会频繁触发缓存失效，CPU不得不从内存读取数据，大幅拖慢计算速度。
• 任务调度的额外开销：std::future的创建、等待与结果获取过程存在同步成本，当单像素计算量较小时（比如低采样数场景），这些调度开销的占比会非常高。

2. 为何8线程与2线程耗时相近？ #

• 调度开销抵消并行收益：当单像素任务的计算量远小于线程调度、锁竞争的开销时，增加线程数量不会提升有效计算的并行度，反而会因更多线程争抢CPU资源、等待锁，导致总调度成本上升，整体耗时基本持平。
• 生产者线程成为瓶颈：若仅用单个生产者线程推送任务，当消费者线程数增加到2以上时，生产者的任务分发速度无法匹配消费者的处理需求，大量消费者线程处于等待任务的空闲状态，无法利用更多CPU核心。
• 缓存竞争加剧：8线程同时访问共享场景数据时，缓存行的争用会更频繁，缓存命中率进一步下降，抵消了多线程并行带来的计算优势。
• CPU有效利用率未提升：你的CPU有16逻辑核心，但8线程时，大量线程消耗在锁等待、任务调度上，真正执行计算的线程占比并未比2线程时显著提升，因此总耗时相近。

内容的提问来源于stack exchange，提问作者Der Fänger im Roggen