了解VS2010 C#并行分析结果

我有一个程序有很多独立的计算,所以我决定并行化它。

我使用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为每个线程从文件中读取。

但是,当我按下同步按钮以查看导致最大延迟的原因时,我看到探查器报告的是function入口线,并且不会报告锁定的部分本身。
它甚至没有报告包含上述代码的function(提醒 – 程序中唯一的锁定 )作为阻塞配置文件的一部分,噪声级别为2%。 当噪音水平为0%时,它会报告程序的所有function,我不明白为什么它们被视为阻塞同步。

所以我的问题是 – 这里发生了什么?
如何将85%的时间用于同步?
如何找出程序中并行部分的问题?

谢谢。

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

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

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

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

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

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

所以我基本上为每个线程实现了一个单独的内存池,但是以非常粗糙的方式,这非常耗时,实际上并不是很好 – 我仍然需要使用很多新的来初始化这些对象,只是现在我全局执行一次,即使不得不增加池的大小,GC线程上的争用也会减少。

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

你能减少分配吗?

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