共享内存 & Actor并发模型哪个更快？

HI，前几天被.NET圈纪检委@懒得勤快问到共享内存和Actor并发模型哪个速度更快。

image

前文传送门：

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

先说结论

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

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

Actor模型易于控制和管理，以消息触发，流水线挨个处理， 思路清晰。

1. 真要说性能，求100000 以内的素数的个数]场景 & 我电脑8c 16g的配置， 我根据这个示例拍脑袋对比。。。。。

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

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

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

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

猜测起来也是共享内存相比默认的Actor模型更具优势。

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

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(); var transfromBlock = new TransformBlock(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(x => { if (x == true) sum++; }, new ExecutionDataflowBlockOptions { EnsureOrdered = false }); transfromBlock.LinkTo(actionBlock, linkOptions); // 准备从pipeline头部开始投递 try { var list = new List { }; 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); } } } }

测试结果如下：

image

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

优化后的Actor模型

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

image

请重新回看《三分钟掌握》 TransformBlock块的细节：

var transfromBlock = new TransformBlock(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是单线程处理输入的消息， 此时我们设置了MaxDegreeOfParallelism参数，参数能在Actor中开启多线程并发执行，但是这里面就不能有共享变量(否则你又得加锁)，恰好我们完成 (1) 迭代判断当前数字是不是素数这一步并不依赖共享对象，所以这一步性能与共享内存模型基本没差别。

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

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

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

image

结束语

请大家仔细对比结论和上图，脱离场景和硬件环境谈性能就是耍流氓，理解不同并发模型的风格和能力是关键，本文仅针对这个示例拍脑袋对比。

实际要针对场景和未来的拓展性、可维护性、可操作性做技术选型 。

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

推荐阅读更多精彩内容

• 三分钟掌握共享内存 & Actor并发模型

  共享内存 面向对象编程中，万物都是对象，数据+行为=对象；多核时代，可并行多个线程，但是受限于资源对象，线程之间存...

  Java_老男孩 阅读 58 评论 0 赞 0

• Actor并发编程模型浅析

  一.Actor模型介绍 在单核 CPU 发展已经达到一个瓶颈的今天，要增加硬件的速度更多的是增加 CPU 核的数目...

  大数据_zzzzMing 阅读 320 评论 0 赞 1

• 并发编程基础知识四 Actor CSP protoactor-go

  参考码农翻身 当多线程并发遇到Actor goroutine, channel 和 CSP并发之痛 Thread，...

  合肥黑 阅读 1,342 评论 0 赞 5

• Actor模型

  传统的游戏服务器要么是单线程要么是多线程，过去几十年里CPU一直遵循摩尔定律发展，带来的结果是单核频率越来越高。而...

  JunChow520 阅读 41,675 评论 12 赞 45

• C/C++并发编程（1）—— 并发/并行、多线程内存模型

  最近看了《七周七并发模型》[1]，对自己熟悉的C/C++并发编程有了很多新的思考。在Google上搜索“C C++...

  Eason_Ye 阅读 9,426 评论 0 赞 4