百度统计
一面之猿网
让这个世界,因为我,有一点点的不一样
炸裂!CGraph性能全面超越taskflow之后,作者却说他更想...

大家好,我是不会写代码却喜欢和chatgpt聊技术的纯序员——ChunelFeng。最近,被微软的chatgpt刷屏,也知道国内有些厂商跟进追随 ,产品被拿来各种对比。恰巧,前段时间知乎上,有人问我,CGraph(色丶图)和 taskflow 之间对比,如何选择。这个问题,让我惊讶于居然已经有人,将小破图和行业的标杆产品拿来做对比了。

image-1679214815730

taskflow是美国犹他大学开源的一款C++17编写的通用并行任务编程库,被广泛应用于科学计算、机器学习、网络编程的高性能计算任务中,也被广泛应用于科学研究领域和CAD相关产品的开发过程。nvidia, jetbrain,ros 等国际大厂和组织,都是taskflow的用户。

image-1679159151968

CGraph从立项之初,就是想做一款简单好用的类taskflow 作品,也一直将taskflow作为模仿和对标的对象。期间,我们也几次和taskflow做过性能对比和竞品分析,结果都是差强人意的。我还记得,我之前来公司面试的时候,被问到CGraph和 taskflow的对比,性能如何。我只能说,功能和用法方面,巴拉巴拉巴拉。性能方面,目前“基本持平”吧。差在自信,懂的都懂,带带弟弟。

image-1679218564855

终于,随着项目的不断发展和迭代,经过各位大神的帮助,和AI技术的辅助下,CGraph在实测的各种指标上,都已经完成了对taskflow的超越。从一个方面,回应了 这个事情,让别人来做,会有什么不一样 这个世纪难题。

开始之前,先上源码链接:https://github.com/ChunelFeng/CGraph

性能对比

我们来看一下各个指标上具体的性能对比。主要分为 多线程并发处理、长链路串行执行、模拟真实dag使用 这三个部分。

  1. 多线程并发处理

在并发处理层面,我们选用的是32节点同时并发执行,循环执行 50w次, 均开8线程处理。

void test() {
    GPipelinePtr pipeline = GPipelineFactory::create();
    CStatus status;
    GElementPtr arr[32];

    UThreadPoolConfig config;
    config.default_thread_size_ = 8;    // 设定8个线程
    config.max_thread_size_ = config.default_thread_size_;
    config.monitor_enable_ = false;    // 关闭扩缩容机制
    pipeline->setUniqueThreadPoolConfig(config);

    for (int i = 0; i < 32; i++) {
        pipeline->registerGElement<MyEmptyNode>(&arr[i]);
    }
    status += pipeline->init();

    /** 其中流程进行计时 **/
    for (int t = 0; t < 500000; t++) {
        pipeline->run();
    }
    /*******************/

    status += pipeline->destroy();
    GPipelineFactory::remove(pipeline);
}

image-1679148293563

看图,这个场景主要考察框架的多并发(8cpu同时跑32线程任务)处理能力,CGraph是明显略胜一筹的。CGraph底层的线程池,采用了多队列的任务模型结构,近期在Ryan哥和风神的帮助下,又定位和优化了pool中的性能瓶颈,有效的减少了抢锁的流程和次数,从而提高了整体调度效率。

  1. 长链路串行执行

这里,我们测试的是超长链路的场景下,框架的执行效率和优化程度。

image-1679149407003

结果是令人振奋的。在串行执行的场景下,CGraph 的性能居然达到了taskflow的近三倍,直接秒杀的节奏。这主要得益于CGraph在底层解析dag结构的时候,采用了 linkable 的优化思路,针对这种情况,将dag可以 linkable的部分,提前退化成一个 list结构,从而极大的减少了调度层面的耗时。

  1. 模拟真实dag使用

最后,我们来模拟的是一个真实的dag使用的例子。形成一个如上的dag结构,大家比较熟悉吧, 在项目过程中,也会经常遇到,对吧。PS:记得在执行值之前,先切换一下动态执行模式。

// 切换动态执行引擎,在dag逻辑较复杂的情况下面,推荐使用动态执行引擎。PS:默认是静态执行引擎
pipeline->setGEngineType(GEngineType::DYNAMIC);

image-1679154121217

执行100w次,测下来CGraph的性能也是略优于taskflow的。这种场景,其实是最有必要说道说道的。大概一年前吧,我们也进行过类似的测试,taskflow的执行耗时,只有我们的一半左右。那个时候,项目还基本只有我一个人在维护,哈哈,是自己太菜无疑了,而且当时的思路比较僵化哈。

image-1679153890866

后来,项目热闹起来了,加入的大佬也越来越多。Ryan哥通过多组实验,精准定位了调度的性能瓶颈点和异常逻辑,为接下来的事情指明了前进方向。叶神实现了动态解图的算法,并且提出了基于提升亲和性的优化思路,用于上述dag调度的情况下,提升显著。虽然色图中的线程池,早已比传统的线程池模型在性能方面 强出数倍,风神还是找出了其中执行思路的一些不足之处,并且进一步完善。

还有,借助最近大火的chargpt,我们也进行针对性的提问,并收获了不少优化并发编程方面经验和思路。一套组合拳下来,终于完成了最后的反杀。更要说明的一点是,CGraph还提供了很多调度相关参数的配置选项,相信根据实际情况进行调优之后,性能一定会更胜一筹的。

当然,我们的社区里还有像坤叔和 乐哥 这种级别的行业大佬,但在这个过程中,并没有发挥什么积极的作用。我在这里稍微强调一下这个事情,意思是小破图今后还有很多进步的空间,并不是说他们不行哦,真的不是说他们不行,大家不要误会哦,嘿嘿嘿。

如何选择

下面,我就结合自己的一些想法,加入一些主观倾向的来回答一下,也算是稍微梳理一下 我们的护城河在哪里 这个问题。我想,选择之前,首先你需要搞想清楚,是否有一些刚需项是无法绕过的。比如:

仅色丶图支持:

  • cpp14或者 cpp11的工程版本(关键)
  • 做整体链路的参数管控(关键)
  • 自定义group逻辑
  • 多dag之间交互
  • 定时器功能

仅taskflow支持:

  • 提供gpu支持(关键)
  • 提供perf功能

image-1679217533834

比如,你的工程版本是cpp11的,你目前就只能选择色丶图,因为不太现实为了引入框架,给taskflow整个工程做降级,对吧。或者,你经常需要实现一些自定义的组合逻辑,甚至是将这些组合的功能开放到你的上游,那你也只能选色图。如果需要在pipeline中,频繁的用到异构计算的话,taskflow就比较合适了,CGraph在这一块并没有做过多的优化。

其他需要考虑的,就是一些比较主观的因素了。比如,如果你比较喜欢面向对象编程的思路,推荐色图,因为色图中,一切皆对象。如果比较喜欢面向流程,直接写lambda的话,taskflow比较适合。

image-1679215165432

如果您的逻辑中,主要都是大量的串行逻辑的话,也是推荐选色丶图的。上面的测试结果也表明了,在这种情况下,对比taskflow,色图针对性优化,将调度性能提升了3倍左右。

还有就是如果你日常reading和coding过程中,对英文资料不是很擅长的话,也推荐你用色丶图。色丶图代码中,包含了很详细的中文注释,所有的介绍文章也是中文的——比如这一篇,属于国货崛起了,哈哈。今后,我们还考虑推出相关的视频介绍,敬请期待。

个人感想

最后,也要表明我的一些观点。性能对比只是竞品分析的一个角度,极端的暴力测试,其实和项目的整体完成度,没有太大的关系,更多是可以打个广告,或者做一页ppt罢了。如果总抓着一个性能点不放、太focus在优化层面的话,最终的结果,可能会像在缺少参与度的偏门项目上拿很多金牌一样,榜单上很好看,但没有太大的实际作用。

作为一个开发者,我认为一款项目成功与否的几个重要标志,还是应该是项目落地场景和周边生态是否丰富,支持了多少用户,和为这些用户解决了多少实际生产过程中遇到的问题。总结一下,就是我刚开始在github上写代码的时候,说的一句口号,build together, power another (共建,赋能)。

在测试过程中,有一点我还是挺感慨的。当我 chatgpt 给我介绍一下taskflow的时候,它的表现很好。当我让它帮我生成一个测试用例的时候,它也可以很快的完成。

image-1679200232127

而当你问它 CGraph是什么,或让它生成一个例子的时候,它的回答,明显就答非所问了。这也可以从一个侧面,说明了taskflow自身的确算是行业的事实标准,而我们的差距,还有很多很多。当然,这也可能跟chatgpt的训练数据,截止到2021年9月为止有关。

我们项目是2021年才开始的,近期我们的项目也有了长足的进步。不光是性能方面,在落地场景方面,色丶图在一线互联网大厂和其他几个领域的公司,也都有了一批用户。我们还积极参与到高校的研究课题中,尽可能的给在校学生提供一些力所能及的帮助。值得一提的是,项目第一个加入的童鞋,和截止目前最后一个加入的童鞋,都是国内985高校的在校学生哦。后浪还是很强劲的,也不知道淘汰我们,是chatgpt,还是下一届毕业的应届生,哎。

image-1679215054178

近期,被chatgpt的各种新闻刷屏,并且已经在实际工作中,体会受益。想着面对这波排山倒海的降维打击,我们这波普通的程序员也就像300年前的纺织工人一样,随时可能面临着行业的洗牌和颠覆。而这又可能才是这个行业正确打开姿势的开端。偶尔用业余时间做的一些小工作,如果能在这无时不在发生的变革中,有一点小小的贡献,而不是随波逐流和听天由命,那自己也会是非常开心的。

好了,感谢你阅读我的博客,也希望这篇文章,能够帮助您在 CGraph 和 taskflow 之间做选择的时候,提供一些参考。很高兴能在项目开始的两年之内,在性能测试方面超越taskflow。但接下来还有很长的路要走,很多的东西要学,很多功能要去实现和完善,很多的瓶颈要去克服。期待你的交流、指导和加入。

mmqrcode1602771241876

                                                                       [2023.03.19 by Chunel]

推荐阅读


个人信息

微信: ChunelFeng
邮箱: chunel@foxmail.com
个人网站:www.chunel.cn
github地址: https://github.com/ChunelFeng

image