【问题标题】:Why Parallel.For gives only so little gain for this particular function?为什么 Parallel.For 只为这个特定功能提供这么少的收益?
【发布时间】:2014-11-25 19:43:38
【问题描述】:

我无法理解为什么我对这个 http://www.codeproject.com/Tips/447938/High-performance-Csharp-byte-array-to-hex-string-t 函数的“并发”实现只有约 20% 的性能提升。

为方便起见,这里是该站点的代码:

static readonly int[] toHexTable = new int[] {
    3145776, 3211312, 3276848, 3342384, 3407920, 3473456, 3538992, 3604528, 3670064, 3735600,
    4259888, 4325424, 4390960, 4456496, 4522032, 4587568, 3145777, 3211313, 3276849, 3342385,
    3407921, 3473457, 3538993, 3604529, 3670065, 3735601, 4259889, 4325425, 4390961, 4456497,
    4522033, 4587569, 3145778, 3211314, 3276850, 3342386, 3407922, 3473458, 3538994, 3604530,
    3670066, 3735602, 4259890, 4325426, 4390962, 4456498, 4522034, 4587570, 3145779, 3211315,
    3276851, 3342387, 3407923, 3473459, 3538995, 3604531, 3670067, 3735603, 4259891, 4325427,
    4390963, 4456499, 4522035, 4587571, 3145780, 3211316, 3276852, 3342388, 3407924, 3473460,
    3538996, 3604532, 3670068, 3735604, 4259892, 4325428, 4390964, 4456500, 4522036, 4587572,
    3145781, 3211317, 3276853, 3342389, 3407925, 3473461, 3538997, 3604533, 3670069, 3735605,
    4259893, 4325429, 4390965, 4456501, 4522037, 4587573, 3145782, 3211318, 3276854, 3342390,
    3407926, 3473462, 3538998, 3604534, 3670070, 3735606, 4259894, 4325430, 4390966, 4456502,
    4522038, 4587574, 3145783, 3211319, 3276855, 3342391, 3407927, 3473463, 3538999, 3604535,
    3670071, 3735607, 4259895, 4325431, 4390967, 4456503, 4522039, 4587575, 3145784, 3211320,
    3276856, 3342392, 3407928, 3473464, 3539000, 3604536, 3670072, 3735608, 4259896, 4325432,
    4390968, 4456504, 4522040, 4587576, 3145785, 3211321, 3276857, 3342393, 3407929, 3473465,
    3539001, 3604537, 3670073, 3735609, 4259897, 4325433, 4390969, 4456505, 4522041, 4587577,
    3145793, 3211329, 3276865, 3342401, 3407937, 3473473, 3539009, 3604545, 3670081, 3735617,
    4259905, 4325441, 4390977, 4456513, 4522049, 4587585, 3145794, 3211330, 3276866, 3342402,
    3407938, 3473474, 3539010, 3604546, 3670082, 3735618, 4259906, 4325442, 4390978, 4456514,
    4522050, 4587586, 3145795, 3211331, 3276867, 3342403, 3407939, 3473475, 3539011, 3604547,
    3670083, 3735619, 4259907, 4325443, 4390979, 4456515, 4522051, 4587587, 3145796, 3211332,
    3276868, 3342404, 3407940, 3473476, 3539012, 3604548, 3670084, 3735620, 4259908, 4325444,
    4390980, 4456516, 4522052, 4587588, 3145797, 3211333, 3276869, 3342405, 3407941, 3473477,
    3539013, 3604549, 3670085, 3735621, 4259909, 4325445, 4390981, 4456517, 4522053, 4587589,
    3145798, 3211334, 3276870, 3342406, 3407942, 3473478, 3539014, 3604550, 3670086, 3735622,
    4259910, 4325446, 4390982, 4456518, 4522054, 4587590
};

public static unsafe string ToHex1(byte[] source)
{
    fixed (int* hexRef = toHexTable)
    fixed (byte* sourceRef = source)
    {
        byte* s = sourceRef;
        int resultLen = (source.Length << 1);

        var result = new string(' ', resultLen);
        fixed (char* resultRef = result)
        {
            int* pair = (int*)resultRef;

            while (*pair != 0)
                *pair++ = hexRef[*s++];
            return result;
        }
    }
}

这是我的“改进”:

public static unsafe string ToHex1p(byte[] source)
{
    var chunks = Environment.ProcessorCount;
    var n = (int)Math.Ceiling(source.Length / (double)chunks);

    int resultLen = (source.Length << 1);

    var result = new string(' ', resultLen);

    Parallel.For(0, chunks, k =>
    {
        var l = Math.Min(source.Length, (k + 1) * n);
        fixed (char* resultRef = result) fixed (byte* sourceRef = source)
        {
            int from = n * k;
            int to = (int)resultRef + (l << 2);

            int* pair = (int*)resultRef + from;
            byte* s = sourceRef + from;
            while ((int)pair != to)
                *pair++ = toHexTable[*s++];
        }
    });

    return result;
}


编辑 1 这就是我对函数计时的方式:

var n = 0xff;
var s = new System.Diagnostics.Stopwatch();
var d = Enumerable.Repeat<byte>(0xce, (int)Math.Pow(2, 23)).ToArray();

s.Start();
for (var i = 0; i < n; ++i)
{
    Binary.ToHex1(d);
}
Console.WriteLine(s.ElapsedMilliseconds / (double)n);

s.Restart();
for (var i = 0; i < n; ++i)
{
    Binary.ToHex1p(d);
}
Console.WriteLine(s.ElapsedMilliseconds / (double)n);

【问题讨论】:

  • 为什么这是在 For 循环内部而不是外部?固定 (char* resultRef = result) 固定 (byte* sourceRef = source) - 见stackoverflow.com/questions/8497018/…
  • @tolanj:我无法回答 OP,但我怀疑这是因为将 fixed 放在匿名方法中比放在外面容易得多,因为有关捕获指针的规则。为了咧嘴笑,我继续在外面用fixed 测试它,发现它并不重要。请注意,在这种情况下,fixed 语句每个线程只执行一次;耗时的循环fixed语句中。
  • @PeterDuniho:同意评估顺序。在 debug-vs-release 上,您的体验与我的很多不同。当您将运行与附加和未附加的调试器进行比较时尤其如此。我见过截然不同的相对时间。也就是说,算法 A 在调试时比 B 快得多,在发布时比 B 慢得多。
  • 我很惊讶没有人问...您使用的是什么版本的 .net? 4.0 的 TPL 实现很糟糕,在我见过的大多数基准测试中,它的开销约为 100%。
  • @PanagiotisKanavos:虽然内存同步确实可能是问题,但在这种情况下不太可能。 result 变量本质上是一个大小为 8 兆字节的数组。因此,对于四个线程,每个线程都在自己的 2 兆字节块上工作。缓存行大小通常为 64 字节,因此 CPU 之间不太可能发生任何类型的内存争用。他们根本不会同时修改相同的缓存行。在最坏的情况下,唯一的争用是在边缘(2 MB 边界周围的 64 个字节)。

标签: c# concurrency parallel-processing task-parallel-library unsafe


【解决方案1】:

在玩了你的例子之后,我得出结论,你看到的大部分时间差异是由于 GC 开销造成的,两种情况下的初始化开销都足够高,即使在 GC 之后,性能差异也相对不重要开销已从测试中移除。

当我切换测试顺序时,并行测试的结束速度比非并行测试快。这是测试不公平的第一个迹象。 :)

当我更改测试以便在每次测试后调用 GC.Collect() 以确保 GC 在随后的测试期间保持安静时,并行版本始终领先。但只是勉强如此;在所有情况下,每个线程的启动时间都超过每个并行测试总持续时间的一半。

作为测试的一部分,我修改了代码,以便跟踪For() 版本的每个线程所花费的实际时间。在这里,我发现这段代码所花费的时间大约是我基于非并行版本所期望的(即相当接近时间除以线程数)。

(当然,也可以使用分析器获取此信息)。

这是我使用GC.Collect() 运行的测试的输出。对于并行测试,这还显示了每个线程的开始时间(相对于整体测试开始时间)和持续时间。

先运行非并行版本,再运行并行版本:

单线程版本:00:00:00.6726813
并行版本:00:00:00.6270247
线程 #0:开始:00:00:00.3343985,持续时间:00:00:00.2925963
线程 #1:开始:00:00:00.3345640,持续时间:00:00:00.2805527

单线程版本:00:00:00.7027335
并行版本:00:00:00.5610246
线程 #0:开始:00:00:00.3305695,持续时间:00:00:00.2304486
线程 #1:开始:00:00:00.3305857,持续时间:00:00:00.2300950

单线程版本:00:00:00.6609645
并行版本:00:00:00.6143675
线程 #0:开始:00:00:00.3391491,持续时间:00:00:00.2750529
线程 #1:开始:00:00:00.3391560,持续时间:00:00:00.2705631

单线程版本:00:00:00.6655265
并行版本:00:00:00.6246624
线程 #0:开始:00:00:00.3227595,持续时间:00:00:00.2924611
线程 #1:开始:00:00:00.3227831,持续时间:00:00:00.3018066

单线程版本:00:00:00.6815009
并行版本:00:00:00.5707794
线程 #0:开始:00:00:00.3227074,持续时间:00:00:00.2480668
线程 #1:开始:00:00:00.3227330,持续时间:00:00:00.2478351

先运行并行版本,再运行非并行版本:

并行版本:00:00:00.5807343
线程 #0:开始:00:00:00.3397320,持续时间:00:00:00.2409767
线程 #1:开始:00:00:00.3398103,持续时间:00:00:00.2408334
单线程版本:00:00:00.6974992

并行版本:00:00:00.5801044
线程 #0:开始:00:00:00.3305571,持续时间:00:00:00.2495409
线程 #1:开始:00:00:00.3305746,持续时间:00:00:00.2492993
单线程版本:00:00:00.7442493

并行版本:00:00:00.5845514
线程 #0:开始:00:00:00.3454512,持续时间:00:00:00.2352147
线程 #1:开始:00:00:00.3454756,持续时间:00:00:00.2389522
单线程版本:00:00:00.6542540

并行版本:00:00:00.5909125
线程 #0:开始:00:00:00.3356177,持续时间:00:00:00.2550365
线程 #1:开始:00:00:00.3356250,持续时间:00:00:00.2552392
单线程版本:00:00:00.7609139

并行版本:00:00:00.5777678
线程 #0:开始:00:00:00.3440084,持续时间:00:00:00.2337504
线程 #1:开始:00:00:00.3440323,持续时间:00:00:00.2329294
单线程版本:00:00:00.6596119

经验教训:

  • 性能测试很棘手,尤其是在托管环境中。像垃圾收集和即时编译这样的东西很难比较苹果与苹果
  • 将字节转换为字符的实际计算成本与程序可能花费时间做的任何其他事情(例如准备和调用线程)相比是完全无关紧要的。这种特殊的算法似乎不值得并行化;即使您确实获得了持续的速度改进,但由于实际计算的所有开销,它是非常微不足道的。

最后一点:此类测试中的另一个错误来源是英特尔的超线程。或者更确切地说,如果您在使用启用超线程的 CPU 计数时进行测试,您会得到误导性的结果。例如,我在基于 Intel i5 的笔记本电脑上对此进行了测试,该笔记本电脑报告有 4 个内核。但是运行四个线程不会比非并行实现接近 4 倍加速,而运行两个线程将接近 2 倍加速(对于正确的问题)。这就是为什么即使我的计算机报告 4 个 CPU,我也只用 2 个线程进行了测试。

在这个测试中,还有很多其他的误导性开销,我认为超线程不会有很大的不同。但这需要注意。

【讨论】:

  • 干得好。奇怪的是GC.Collect 甚至没有解决问题。看看你的结果是否与 app.config 中的gcServer enabled=true 不同会很有趣。
  • 你所说的“平局”是什么意思?使用GC.Collect() 实际上确实允许并行版本始终如一地获胜。由于非并行开销,它并没有赢得太多。
  • 那我不明白你的结果。在第一种情况下(并行运行第二),看起来并行版本平均为 25 毫秒。在第二种情况下(首先并行运行),看起来并行版本的运行时间约为 13 毫秒。我误会了什么?
  • 我认为我没有充分解释输出的格式。总的测试时间是只有时间的行(即没有其他文本)。带有“开始”和“持续时间”字样的行是每个线程的时间仅适用于并行版本。对不起,如果我让事情变得比他们需要的更混乱。
  • 在我的 3930k 上,对于 2^23 数据大小、并行和顺序,我每次 13 毫秒和 18 毫秒都得到相同的结果。不管我先运行哪个,或者我是否在它们之间调用 GC.Collect 或者我是否单独运行它们。实际上用 3930k 我什至看不到问题......
【解决方案2】:

我在第一个答案的评论中读到(顺便说一下,这比问题和 cmets 提供的信息更多)这些测试的执行时间最长约为 25 毫秒。

对此有很多话要说,但首先是“浪费程序员的好时间!”

这是您过度优化的明显案例。乍一看代码,我想“世界上为什么会有人想要并行这个?”您正在执行非常快速的按位运算。首先没有足够的性能损失来证明并行性是合理的。

现在,谈谈您的测试差异。 TPL 是一个复杂的库,并行性比单线程复杂一个数量级。因此,当您运行测试时,有许多因素会发挥作用,其中一些(但绝不是全部)在各种 cmets 中都有提及。每个因素都以不可预测的方式影响结果,您可以将每个因素视为增加了一点变化。最后,您的测试结果没有足够的能力来区分两者,这又是过度优化的另一个迹象。

作为程序员,作为一般规则,我们需要记住我们的时间非常昂贵,尤其是与计算机时间相比时。编程时很少有机会获得真正的增值性能增益,并且通常集中在非常昂贵的处理或需要从远程服务器请求的情况等。肯定有需要它的时候,但这不是其中之一他们。

【讨论】:

    猜你喜欢
    • 2018-02-22
    • 1970-01-01
    • 2021-07-24
    • 2012-09-16
    • 1970-01-01
    • 2019-11-22
    • 1970-01-01
    • 1970-01-01
    • 2011-05-23
    相关资源
    最近更新 更多