Question

我有一个包含许多独立计算的程序，因此我决定将其并行化。

我使用Parallel.For / Each。

双核机器的结果还可以 - 大部分时间CPU利用率约为80％-90％。但是，使用双Xeon机器（即8个内核），我只获得了大约30％-40％的CPU利用率，尽管该程序在并行部分上花费了相当多的时间（有时超过10秒），我看到它使用了与串行部分相比，这些部分中大约有20-30个线程。每个线程需要1秒以上才能完成，因此我认为没有理由不能并行工作 - 除非存在同步问题。

我使用了VS2010的内置分析器，结果很奇怪。即使我只在一个地方使用锁，分析器也会报告大约85％的程序时间花在同步上（5-7％睡眠，5-7％执行，1％IO）。

锁定的代码只是一个缓存（字典）get / add：

bool esn_found;
lock (lock_load_esn)
    esn_found = cache.TryGetValue(st, out esn);
if(!esn_found)
{
    esn = pData.esa_inv_idx.esa[term_idx];
    esn.populate(pData.esa_inv_idx.datafile);
    lock (lock_load_esn)
    {
        if (!cache.ContainsKey(st))
            cache.Add(st, esn);
    }
}

lock_load_esn 是Object类型的静态成员 esn.populate 使用单独的StreamReader为每个线程从文件中读取。

然而，当我按下同步按钮查看导致延迟最多的按钮时，我看到探查器报告的是功能入口线，而不会报告锁定的部分。
它甚至不会报告包含上述代码的函数（提醒 - 程序中唯一的 lock ）作为阻塞配置文件的一部分，噪声级别为2％。当噪音水平为0％时，它会报告程序的所有功能，我不明白为什么它们被视为阻塞同步。

所以我的问题是 - 这里发生了什么？ 85％的时间花在同步上怎么样呢？如何找出程序中并行部分的实际问题？

感谢。

更新：深入研究线程后（使用非常有用的可视化工具）我发现大部分同步时间都花在等待GC线程完成内存分配上由于通用数据结构调整操作，因此需要分配。

我将不得不看看如何初始化我的数据结构，以便它们在初始化时分配足够的内存，可能避免GC线程的这种竞争。

我今天晚些时候会报告结果。

更新：看来内存分配确实是导致问题的原因。当我在并行执行的类中使用所有词典和列表的初始容量时，同步问题更小。我现在只有大约80％的同步时间，CPU利用率达到70％（之前的峰值只有40％左右）。

我进一步钻进每个线程，发现现在很多调用GC分配用于分配不属于大字典的小对象。

我通过为每个线程提供一个预先分配的这类对象池来解决这个问题，我使用它而不是调用“new”函数。

所以我基本上为每个线程实现了一个单独的内存池，但是以非常粗糙的方式，这非常耗时且实际上不是很好 - 我仍然需要使用大量的 new 对于这些对象的初始化，现在我只进行一次全局操作，并且GC线程上的争用较少，即使必须增加池的大小。

但这绝对不是我喜欢的解决方案，因为它不容易推广，我不想写自己的内存管理器。
有没有办法告诉.NET为每个线程分配预定义的内存量，然后从本地池中获取所有内存分配？

Answer 1

你可以减少分配吗？

我有过几次类似的经历，看着糟糕的性能，并发现问题的核心是GC。但是，在每种情况下，我都发现我在一些内环中意外地耗尽了记忆，不必要地分配了大量的临时物体。我会仔细查看代码，看看是否有可以删除的分配。我认为程序很少需要在内循环中进行大量分配。

了解VS2010 C＃并行分析结果

1 个答案: