Parallel.For

简介:
Parallel.For方法并行的执行for循环,它又多个重载。最常用的就是
<

本人测试了一个求和方法,分别用传统的for语句和Parallel.For,结果发现,for语句不仅计算正确,而且速度比并行更快。而Parallel.For计算机结果还是不正确的。
这是由于Parallel.For在计算时要调用委托,也会消耗相当量的开销,所以仅仅在方法开销很大的时候,用并行才能体现出效率。
其次,之前的文章介绍过,给变量赋值对于大多数cpu来说都不是原子操作,而是需要分成3步的。 C#的Interlocked类 所以导致sum求和并不能始终会有正确值。解决方法是加锁,用lock或者Interlocked
 
即便这样, 经过测试:parallel.For的最后一个参数,Action委托 直接写拉姆达表达式效率最低。写匿名委托效率高一些。不知道这是为何。
 
当在for循环里运行while循环来模拟复杂计算时,并行的For方法明显比单纯的for循环效率就高了。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Diagnostics;

namespace ConsoleApplication1
{
    class Program
    {
        static long sum = 0;
        static void Main(string[] args)
        {
            //sequential
            Console.WriteLine("sequential");
            object alock = new object();
            var sw = Stopwatch.StartNew();
            for (int i = 0; i < 100000; i++)
            {
                sum += i;
            }
            Console.WriteLine(sw.Elapsed.ToString());
            Console.WriteLine(sum.ToString());

            Console.WriteLine("parallel");
            sum = 0;

            sw = Stopwatch.StartNew();
             Parallel.For(0, 100000, (i) =>
            {
                sum += i;
            });
            Console.WriteLine(sw.Elapsed.ToString());
            Console.WriteLine(sum.ToString());

            sum = 0;
            sw = Stopwatch.StartNew();
             Parallel.For(0, 100000, delegate(int i)
            {
                sum += i;
            });
            Console.WriteLine(sw.Elapsed.ToString());
            Console.WriteLine(sum.ToString());

            sum = 0;
            sw = Stopwatch.StartNew();
             Parallel.For(0, 100000, a);
            Console.WriteLine(sw.Elapsed.ToString());
            Console.WriteLine(sum.ToString());

            sw = Stopwatch.StartNew();
            for (int i = 0; i < 20; i++)
            {
                int j = 0;
                while (j < 100000)
                {
                    j++;
                }
            }
            Console.WriteLine(sw.Elapsed.ToString());


            sw = Stopwatch.StartNew();
            Parallel.For(0, 20, delegate(int i)
            {
                int j = 0;
                while (j < 100000)
                {
                    j++;
                }
            });
            Console.WriteLine(sw.Elapsed.ToString());

        }

        static Action<int> a = Sum;
        static void Sum(int i)
        {
            sum += i;
        }

    }
}
 
















本文转自cnn23711151CTO博客,原文链接: http://blog.51cto.com/cnn237111/538289 ,如需转载请自行联系原作者

相关文章
|
分布式计算 Spark
通过spark.default.parallelism谈Spark并行度
本篇文章首先通过大家熟知的一个参数spark.default.parallelism为引,聊一聊Spark并行度都由哪些因素决定?
通过spark.default.parallelism谈Spark并行度
|
负载均衡 安全 Go
译 | Concurrency is not Parallelism(三)
译 | Concurrency is not Parallelism(三)
57 0
|
缓存 Go
译 | Concurrency is not Parallelism(四)
译 | Concurrency is not Parallelism
53 0
|
程序员 Linux Go
译 | Concurrency is not Parallelism(一)
译 | Concurrency is not Parallelism
62 0
|
算法 安全 Shell
译 | Concurrency is not Parallelism(二)
译 | Concurrency is not Parallelism(二)
51 0
|
分布式计算 Java Spark
Optimizing Spark job parameters
Optimizing Spark job parameters
234 0
|
分布式计算 Spark
Spark - ReturnStatementInClosureException: Return statements aren‘t allowed in Spark closures
Spark 使用 RDD 调用 Filter 函数时,dirver 端卡住,报错 ReturnStatementInClosureException: Return statements aren't allowed in Spark closures,即闭包内无法使用 return 函数。
320 0
Spark - ReturnStatementInClosureException: Return statements aren‘t allowed in Spark closures
|
SQL 分布式计算 IDE
Spark AQE中的CoalesceShufflePartitions和OptimizeLocalShuffleReader
Spark AQE中的CoalesceShufflePartitions和OptimizeLocalShuffleReader
401 0
Spark AQE中的CoalesceShufflePartitions和OptimizeLocalShuffleReader
|
SQL 分布式计算 调度
【Spark】(七)Spark partition 理解 / coalesce 与 repartition的区别
【Spark】(七)Spark partition 理解 / coalesce 与 repartition的区别
501 0
|
SQL 人工智能 分布式计算
Incorporating Partitioning and Parallel Plans into the SCOPE optimizer
这篇paper中讨论是的Microsoft的cosmos DB,其本身是一个海量数据的大规模计算平台,有些类似hadoop,使用的是一种类SQL的脚本,叫做SCOPE,针对SCOPE的优化器负责生成最优的执行计划。在1998年前后Microsoft基本丢弃了Sybase原有的优化器实现,并由Graefe主导重写了基于cascades的优化器。因此和Microsoft所有其他的数据库产品一样,SCOPE optimizer也是基于Cascades的transformation-based的优化器。
334 0
Incorporating Partitioning and Parallel Plans into the SCOPE optimizer