开发制作一个网站,徐州低成本建站,wordpress主题中的psd,百度上海总部HI#xff0c;前几天被.NET圈纪检委懒得勤快问到共享内存和Actor并发模型哪个速度更快。前文传送门#xff1a;《三分钟掌握共享内存 Actor并发模型》说实在#xff0c;我内心10w头羊驼跑过.....先说结论1.首先两者对于并发的风格模型不一样。共享内存利用多核CPU的优… 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中的所有块默认是单线程的这就意味着完成以上两步的TransfromBlock和ActionBlock都是以一个线程挨个处理消息数据 (这也是Dataflow的设计初衷形成清晰单纯的流水线)。猜测此时共享内存相比默认的Actor模型更具优势。使用NUnit做单元测试数据量从小到大: 10_000,50_000,100_000,200_000,300_000,500_000using 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 BufferBlockint();var transfromBlock new TransformBlockint, 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 ActionBlockbool(x {if (x true)sum;}, new ExecutionDataflowBlockOptions { EnsureOrdered false });transfromBlock.LinkTo(actionBlock, linkOptions);// 准备从pipeline头部开始投递try{var list new Listint { };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($mdnum post failurenum:{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 块的细节var transfromBlock new TransformBlockint, 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 { MaxDegreeOfParallelism50, EnsureOrdered false }); // 这里开启多线程并发
上面说到默认的Actor是以单线程处理输入的消息此次我们对这个TransfromBlock 块设置了MaxDegreeOfParallelism 参数这个参数能在Actor中开启多线程并发执行但是这里面就不能有共享变量(否则你又得加锁)恰好我们完成 (1) 迭代判断当前数字是不是素数这一步并不依赖共享对象所以这(1)步开启多线程以后性能与共享内存模型基本没差别。那为什么总体性能慢慢超过共享内存这是因为执行第二步(2) 如果是素数执行sum 共享内存要加/解锁线程切换; 而Actor单线程挨个处理, 总体上Actor就略胜共享内存模型了。这里再次强调Actor模型执行第二步(2) 如果是素数执行sum不可开启MaxDegreeOfParallelism,因为依赖了共享变量sum结束语Thats All 感谢.NET圈纪检委懒得勤快促使我重温了单元测试的写法 深度分析Actor模型风格。请大家仔细对比结论和上图脱离场景和硬件环境谈性能就是耍流氓理解不同并发模型的风格和能力是关键 针对场景和未来的拓展性、可维护性、可操作性做技术选型 。本文内容和制图均为原创文章永久更新地址请参阅左下角原文如对您有所帮助请一键三连方便的话置一个星标 ~。。~。专题相关 一网打尽 三分钟掌握共享内存 Actor并发模型 你管这叫线程安全? .Net线程同步技术解读 Redis分布式锁抽丝剥茧 看过这么多爆文依旧走不好异步编程这条路 TPL Dataflow组件应对高并发,低延迟要求 如何利用.NETCore向Azure EventHubs准实时批量发送数据 难缠的布隆过滤器这次终于通透了扫码关注我们不会让您失望的。
