了解 VS2010 C# 并行分析结果

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 从文件中读取数据。

但是，当我按“同步”按钮查看导致最大延迟的原因时，我发现探查器报告的行是函数入口行，并且不报告锁定的部分本身。
它甚至没有将包含上述代码的函数（提醒 - 程序中唯一的锁）报告为噪声级别 2% 的阻塞配置文件的一部分。当噪音水平为 0% 时，它会报告程序的所有功能，我不明白为什么它们被视为阻塞同步。

所以我的问题是 - 这是怎么回事？
怎么可能85%的时间都花在同步上？
我如何找出程序并行部分的真正问题是什么？

谢谢。

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

我必须了解如何初始化我的数据结构，以便它们在初始化时分配足够的内存，从而可能避免 GC 线程的竞争。

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

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

我进一步深入研究每个线程，发现现在对 GC allocate 的许多调用都是为了分配不属于大字典的小对象。

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

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

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

Answer 1

能不能少分配一点？

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