为什么我的代码没有通过多线程 Parallel.For 循环加速？

Question

我尝试使用System.Threading.Tasks 库将一个简单的顺序循环转换为并行计算循环。 代码编译，返回正确结果，但不节省任何计算成本，否则耗时较长。

---

编辑：对不起，伙计们，我可能过于简化了这个问题，并在这样做时犯了一些错误。 为了附加更多信息，我在 i7-4700QM 上运行代码，它在 Grasshopper 脚本中被引用。 这是实际的代码。我也切换到了非线程局部变量

public static class LineNet
{        
    public static List<Ray> SolveCpu(List<Speaker> sources, List<Receiver> targets, List<Panel> surfaces)
    {
        ConcurrentBag<Ray> rays = new ConcurrentBag<Ray>();
        for (int i = 0; i < sources.Count; i++)
        {
            Parallel.For(
                0,
                targets.Count,
                j =>
                {
                    Line path = new Line(sources[i].Position, targets[j].Position);
                    Ray ray = new Ray(path, i, j);
                    if (Utils.CheckObstacles(ray,surfaces))
                    {
                        rays.Add(ray);
                    }

                }
                );
        }
    }
}

Grasshopper 实现只是收集sourcestargets 和surfaces，调用方法Solve 并返回rays。 我知道将工作负载分派到线程是昂贵的，但它是如此昂贵吗？ 还是ConcurrentBag 只是阻止并行计算？

另外，我的类是不可变的 (?)，但如果我使用常见的 List，内核会中止操作并引发异常，有人能说出原因吗？

Answer 1

如果没有可靠地重现问题的良好Minimal, Complete, and Verifiable code example，就不可能提供明确的答案。您发布的代码甚至看起来都不是真实代码的摘录，因为声明为方法返回类型的类型与return 语句实际返回的值不同。

但是，您发布的代码显然不能很好地使用Parallel.For()。您的 Line 构造函数要证明并行创建项目的任务是相当昂贵的。需要明确的是，这是这里唯一可能的胜利。

最后，您仍然需要将您创建的所有Line 实例聚合到一个列表中，因此为Parallel.For() 任务创建的所有这些中间列表只是纯粹的开销。并且聚合必然是序列化的（即一次只有一个线程可以将一个项目添加到result 集合中），并且以最坏的方式（每个线程在放弃锁定之前只能添加一个项目和另一个线程有机会抓住它）。

坦率地说，您最好将每个本地 List<T> 存储在一个集合中，然后在 Parallel.For() 返回后在主线程中一次聚合它们。并不是说这可能会使代码比直接的非并行实现更好。但至少它不太可能变得更糟。 :)

最重要的是，您似乎没有可以从并行化中受益的工作负载。如果您不这么认为，则需要以更清晰、更详细的方式解释该想法的基础。

如果我使用一个通用 List 内核会中止操作并引发异常，有人能说出原因吗？

您已经在使用（看起来）List<T> 作为每个任务的本地数据，确实应该没问题，因为任务不共享它们的本地数据。

但是，如果您问为什么尝试使用List<T> 而不是ConcurrentBag<T> 作为result 变量时会出现异常，那么这完全是意料之中的。 List<T> 类不是线程安全的，但Parallel.For() 将允许它运行的每个任务与所有其他任务同时执行localFinally 委托。所以你有多个线程都试图同时修改同一个非线程安全的集合。这是灾难的秘诀。你很幸运你得到了例外；实际行为是未定义的，您很可能会简单地破坏数据结构，导致运行时异常。