大尺寸Mandelbrot分形图像的高效计算方案咨询

性能问题根源与优化建议 #

你多线程实现比单线程慢的核心原因是你在循环内直接调用Graphics对象的绘图方法，GDI+的Graphics实例是线程不安全的，多线程操作时要么触发异常要么会产生大量锁竞争开销，完全抵消了并行计算的收益。另外单循环版本的性能瓶颈很大概率也不在分形计算本身，而是在GDI+逐点绘图的开销上。

CPU端优化方案

• 拆分计算与绘图流程：预先初始化一个和分辨率匹配的颜色/迭代次数二维数组，计算阶段只把每个点的结果写入数组，不涉及任何绘图操作，所有计算完成后再统一把数组内容写入Bitmap，彻底消除多线程计算时的共享资源竞争。
• 改用官方并行实现：不要自己手动拆分Thread/Task，用Parallel.For按行或者按32x32的瓦块拆分计算任务，运行时会自动做负载均衡，同时注意数组内存排布要避免伪共享（相邻线程不要操作同一段缓存行对应的内存地址）。
• 优化循环逻辑：把浮点变量循环改成整数循环，通过整数索引计算坐标值，避免浮点累加带来的精度误差和额外开销：

double step = ((px - mx) / points) * 0.5d;
// 外层用整数循环做并行
Parallel.For(0, points, i => {
    double x = mx + i * step;
    for (int j = 0; j < points; j++) {
        double y = my + j * step;
        // 仅把计算结果写入数组，不操作绘图对象
        resultArr[i,j] = ParseDot(CreateDot(new Complex(x, y)));
    }
});

• 优化绘图逻辑：不要用Graphics.DrawPoint逐点绘制，直接用LockBits锁定Bitmap的内存缓冲区，把预计算好的颜色数组直接拷贝到缓冲区，绘图速度能提升数十倍。
• 计时改用Stopwatch类，比DateTime.Now精度高很多，避免统计误差。

OpenCL加速相关

这类分形计算是典型的完全并行任务，每个点的计算完全独立，非常适合用OpenCL加速，而且OpenCL不绑定特定厂商硬件，Intel核显、AMD显卡甚至CPU本身都可以作为OpenCL的运行设备，就算用核显运行，性能也通常比CPU单线程高几十倍，远超过手动多线程优化的效果。你可以用C#的OpenCL绑定库实现核函数调用，把所有点的计算逻辑放到设备端执行，最后一次性读回结果数组即可。

内容的提问来源于stack exchange，提问作者Neoz