前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >共享内存 & Actor并发模型到底哪个快?

共享内存 & Actor并发模型到底哪个快?

作者头像
有态度的马甲
发布2021-08-05 09:59:18
6340
发布2021-08-05 09:59:18
举报
文章被收录于专栏:精益码农
HI,前几天被.NET圈纪检委@懒得勤快问到共享内存Actor并发模型哪个速度更快。

前文传送门:《三分钟掌握共享内存 & Actor并发模型

说实在,我内心10w头羊驼跑过.....

先说结论

1.首先两者对于并发的风格模型不一样。

共享内存利用多核CPU的优势,使用强一致的锁机制控制并发, 各种锁交织,稍不注意可能出现死锁,更适合熟手。

Actor模型易于控制和管理,以消息触发、流水线挨个处理,天然分布式,思路清晰。

2.真要说性能,求100_000 以内的素数的个数]场景 & 电脑8c 16g的配置

•2.1 理论上如果以默认的Actor并发模型来做这个事情,共享内存模型是优于Actor模型的;•2.2 上文中我对于Actor做了多线程优化,Actor模型性能慢慢追上来了。 下面请听我唠嗑。

默认Actor模型

计算[100_000内素数的个数], 分为两步: (1) 迭代判断当前数字是不是素数 (2) 如果是素数,执行sum++

完成以上两步,共享内存模型均能充分利用CPU多核心。

Actor模型:与TPL中的原语不同,TPL Datflow中的所有块默认是单线程的,这就意味着完成以上两步的TransfromBlockActionBlock都是以一个线程挨个处理消息数据 (这也是Dataflow的设计初衷,形成清晰单纯的流水线)。

猜测此时:共享内存相比默认的Actor模型更具优势。

使用NUnit做单元测试,数据量从小到大: 10_000,50_000,100_000,200_000,300_000,500_000

代码语言:javascript
复制
using NUnit.Framework;
using System;
using System.Threading.Tasks;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks.Dataflow;

namespace TestProject2
{
    public class Tests
    {
        [TestCase(10_000)]
        [TestCase(50_000)]
        [TestCase(100_000)]
        [TestCase(200_000)]
        [TestCase(300_000)]
        [TestCase(500_000)]
        public void ShareMemory(int num)
        {
            var sum = 0;
            Parallel.For(1, num + 1, (x, state) =>
            {
                var f = true;
                if (x == 1)
                    f = false;
                for (int i = 2; i <= x / 2; i++)
                {
                    if (x % i == 0)  // 被[2,x/2]任一数字整除,就不是质数
                        f = false;
                }
                if (f == true)
                {
                    Interlocked.Increment(ref sum);// 共享了sum对象,“++”就是调用sum对象的成员方法
                }
            });
            Console.WriteLine($"1-{num}内质数的个数是{sum}");
        }

        [TestCase(10_000)]
        [TestCase(50_000)]
        [TestCase(100_000)]
        [TestCase(200_000)]
        [TestCase(300_000)]
        [TestCase(500_000)]
        public async Task Actor(int num)
        {
            var linkOptions = new DataflowLinkOptions { PropagateCompletion = true };
            var bufferBlock = new BufferBlock<int>();
            var transfromBlock = new TransformBlock<int, bool>(x =>
            {
                var f = true;
                if (x == 1)
                    f = false;
                for (int i = 2; i <= x / 2; i++)
                {
                    if (x % i == 0)  // 被[2,x/2]任一数字整除,就不是质数
                        f = false;
                }
                return f;
            }, new ExecutionDataflowBlockOptions { EnsureOrdered = false });

            var sum = 0;
            var actionBlock = new ActionBlock<bool>(x =>
            {
                if (x == true)
                    sum++;
            }, new ExecutionDataflowBlockOptions {  EnsureOrdered = false });
            transfromBlock.LinkTo(actionBlock, linkOptions);
            // 准备从pipeline头部开始投递
            try
            {
                var list = new List<int> { };
                for (int i = 1; i <= num; i++)
                {
                    var b = await transfromBlock.SendAsync(i);
                    if (b == false)
                    {
                        list.Add(i);
                    }
                }
                if (list.Count > 0)
                {
                    Console.WriteLine($"md,num post failure,num:{list.Count},post again");
                    // 再投一次
                    foreach (var item in list)
                    {
                        transfromBlock.Post(item);
                    }
                }
                transfromBlock.Complete();  // 通知头部,不再投递了; 会将信息传递到下游。
                actionBlock.Completion.Wait();  // 等待尾部执行完
                Console.WriteLine($"1-{num} Prime number include {sum}");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"1-{num} cause exception.",ex);
            }   
        }
    }
}

测试结果如下:

测试结果印证我说的结论2.1

优化后的Actor模型

那后面我对Actor做了什么优化呢? 能产生下图的2.2结论。

请重新回看《三分钟掌握共享内存 & Actor并发模型》 TransfromBlock 块的细节:

代码语言:javascript
复制
var transfromBlock = new TransformBlock<int, bool>(x =>
    {
          var f = true;
          if (x == 1)
             f = false;
          for (int i = 2; i <= x / 2; i++)
          {
                if (x % i == 0)  // 被[2,x/2]任一数字整除,就不是质数
                   f = false;
           }
           return f;
     }, new ExecutionDataflowBlockOptions { MaxDegreeOfParallelism=50, EnsureOrdered = false }); // 这里开启多线程并发

上面说到默认的Actor是以单线程处理输入的消息,此次我们对这个TransfromBlock 块设置了MaxDegreeOfParallelism 参数,

这个参数能在Actor中开启多线程并发执行,但是这里面就不能有共享变量(否则你又得加锁),恰好我们完成 (1) 迭代判断当前数字是不是素数这一步并不依赖共享对象,所以这(1)步开启多线程以后性能与共享内存模型基本没差别。

那为什么总体性能慢慢超过共享内存?

这是因为执行第二步(2) 如果是素数,执行sum++, 共享内存要加/解锁,线程切换; 而Actor单线程挨个处理, 总体上Actor就略胜共享内存模型了。

这里再次强调,Actor模型执行第二步(2) 如果是素数,执行sum++,不可开启MaxDegreeOfParallelism,因为依赖了共享变量sum

结束语

That's All, 感谢.NET圈纪检委@懒得勤快促使我重温了单元测试的写法 & 深度分析Actor模型风格。

请大家仔细对比结论和上图脱离场景和硬件环境谈性能就是耍流氓,理解不同并发模型的风格和能力是关键, 针对场景和未来的拓展性、可维护性、可操作性做技术选型 。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-07-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 精益码农 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 先说结论
  • 默认Actor模型
  • 优化后的Actor模型
  • 结束语
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档