2

为什么 PLINQ 输出不同于顺序处理和 Parallel.For 循环

我想添加 10,000,000 个数字的平方根之和。这是 3 种情况的代码：

顺序for循环：

double sum = 0.0;
for(int i = 1;i<10000001;i++)
sum += Math.Sqrt(i);

输出为：21081852648.717

现在使用 Parallel.For 循环：

object locker = new object();
double total ;

Parallel.For(1,10000001,
()=>0.0,
(i,state,local)=> local+Math.Sqrt(i),
(local)=>
{
  lock(locker){ total += local; }
}
);

输出为：21081852648.7199

现在使用 PLINQ

double tot =  ParallelEnumerable.Range(1, 10000000)
                .Sum(i => Math.Sqrt(i));

输出为：21081852648.72

为什么 PLINQ 输出与 Parallel.For 和 Sequential for 循环之间存在差异？

4

1 回答 1

5

我强烈怀疑这是因为双打算术并不是真正的关联。对值求和时可能会丢失信息，确切丢失的信息取决于操作的顺序。

这是一个显示该效果的示例：

using System;

class Test
{
    static void Main()
    {
        double d1 = 0d;
        for (int i = 0; i < 10000; i++)
        {
            d1 += 0.00000000000000001;
        }
        d1 += 1;
        Console.WriteLine(d1);

        double d2 = 1d;
        for (int i = 0; i < 10000; i++)
        {
            d2 += 0.00000000000000001;
        }
        Console.WriteLine(d2);
    }
}

在第一种情况下，我们可以多次添加非常小的数字，直到它们变得足够大以在添加到 1 时仍然相关。

在第二种情况下，将 0.00000000000000001 添加到 1 始终只会导致 1，因为双精度中没有足够的信息来表示 1.00000000000000001 - 所以最终结果仍然只是 1。

编辑：我想到了另一个可能令人困惑的方面。对于局部变量，JIT 编译器能够（并且允许）使用 80 位 FP 寄存器，这意味着可以在更少的信息丢失的情况下执行算术运算。对于肯定必须是 64 位的实例变量，情况并非如此。在您的 Parallel.For 案例中，该total变量实际上是生成类中的实例变量，因为它是由 lambda 表达式捕获的。这可能会改变结果——但这很可能取决于计算机架构、CLR 版本等。

于 2011-02-18T07:32:21.973 回答