百度统计
一面之猿网
让这个世界,因为我,有一点点的不一样
从零开始主导一款收录于awesome-cpp的项目,是一种怎样的体验?
谢邀!
其实,根本没有人邀请,好么。 —— 郝博(华为数据库内核高级架构师)

大家好,我是不会写代码却总想搞个大新闻的纯序员——ChunelFeng,最近正值新年假期,小纯在这里祝福大家新春快乐,兔飞猛进。

前阵子,有朋友聊到,CGraph仓库代码多起来了,想入门源码,一时之间不知道如何下手了。于是,小纯就抽假期的时间,给大家整理了一份xmind文件,梳理了CGraph的src文件夹下的所有内容简介和之间的关联,希望对大家有所帮助。

image-1674885656801

再想,前阵子小破图作为唯一一个readme是非英文的项目,被收录于 awesome-cpp 列表,想写一点内容来纪念一下,也正好是当做总结和今后的展望了。接下来,我就结合写CGraph项目的思路和过程,总结一下我的心得和感悟吧。当然,我知道这只是里程碑,但远不是终点。

做加法

CGraph项目开始的定位,是一款简单好用的dag调度框架。刚开始,仅用了几天假期,就跑通了demo版本。然后,我们围绕着“简单好用”、“dag”、“调度”、“框架”这几个词,做了很多事情。

image-1674884967294

我们优化了dag的解图思路,支持了静态、动态解图两种执行模式,可以自行切换,分别适配不同的场景需求。调度方面,我们对线程池进行了大量的调优,并且开放出来相关参数,供用户配置。也进行了一些有针对性的设计。

为了解决既有老逻辑的迁移到CGraph的问题,我们推出了函数注入的功能。使得原有的功能函数,甚至是代码片段,都可以很快的接入pipeline中,从而成为dag的一个部分。

image

作为一款框架,我们在完成dag调度本职工作的同时,又加入了切面功能、定时触发和信号触发功能。针对类似视频的流式长链路数据处理,我们又引入了消息机制,来实现多个pipeline之间的交互,从而组成了一个更大的、可以分段执行的dag网络。

对比taskflow中没有涉及的参数管控,我们实现了一套参数管理机制,从而优化了整个链路的数据传递体验。也在性能几乎一致的情况下,解决了cpp11版本的兼容性。相比于最低支持cpp17的taskflow,极大的扩展了使用范围和适配情况。

做减法

我之前是玩三国杀的。早期,一共只有30+个武将,学习他们的技能非常简单。但是随着游戏版本的迭代,引入了几百个武将,每个武将又有自己的技能,这极大的增加了新人入门的门槛,也有很多人因此弃坑了。但不断迭代功能(武将),又是项目(游戏公司)继续发展下去的必由之路。

image-1674885005341

为了尽可能的在演进的过程中保持简单,我们在coding的过程中,将所有的dag执行逻辑,抽象为 object + manager 的思路,形成了一套编程范式。用这种方式表达所有新增的功能,并且对外部提供一致的接口。

在开发过程中,我也养成一个意识,就是一块类似的代码,如果写了三次或以上,就需要考虑进行一些统一封装了。可以是函数,可以是类,可以是宏,也可以是模板。一阵子下来,项目的代码量降下来了,可维护性和可扩展性也高了。

我上学的时候几乎没写过代码,毕业后,想完成我做程序员的梦想,刚开始只能去一些很弱的公司。我比很多人更能理解,一个低端coder可能差到什么程度。不懂cmake?没用过submodule依赖?没编译过工程?没用过git?没用过docker?没用过linux?没有关系,不会可以慢慢学。我希望可以做到,无论你现在处于什么样的状态,只要是有需要的话,都可以跑起来CGraph的功能,看看效果,想想跟你的需求是否合拍,然后再决定是否进一步了解下去。

为此,我们通过宏定义,无缝的兼容了mac/linux/windows三种系统,不加入任何三方引入,没有任何环境依赖,兼容了C++11和以上所有的版本,并详尽的描述了项目编译和使用流程。即便是没有编译环境的机器,也可以通过online环境来查看代码和运行demo。

image-1674885149871

做减法,还体现在一些功能层面的权衡。之前我们提过想实现一个any的group逻辑,效果是n个算子加入其中,只要其中有1个执行完成,就继续往下执行。但最终也因为可能会引入的一些长尾问题,而放弃了。今后我们会重新评估这个功能的可行性。

也正是因为我们在开发过程中持续做的这些减法,确保了当前功能的稳定性和可解释性。在今后演进的过程中,我们也会 keep CGraph simple and stupid,持续打磨简单好用的产品。

做乘法

一个人的力量终归太微小了。好在这一路上,慢慢的加入了很多伙伴。大家一起优化、推广、落地,一步一步实现着成倍、成指数级别的提升。

image-1674885197839

去年上半年,浙大的王博士主导 GraphANNS 项目开始实施,通过将ANNS算法算子化+逐个调优的方式,来实现算法研究和优化。年中,百度的Yaha童鞋提供了项目对应的 sonarqube服务,基于此消灭了项目的一些冗余代码。来自魔门塔的 logerrors 童鞋贡献了xmake,丰富了项目的编译方式。下半年,阿里的Ysi童鞋,pr了动态解图的执行逻辑,极大的优化了复杂dag逻辑的执行效率。

我们的线程池优化的相关文章,也发布在doocs社区的公众号上,从而有了更广泛的触达。作为awesome-cpp上唯一一个没有英文readme的项目,我们英语18级的专业人士翻译的英文版本readme,也很快就要完成了。

CGraph项目本身是没有三方依赖,为了快速的扩展功能,丰富应用场景和领域,我们也开展了碰瓷名项目活动。在 CGraph-NIO 项目中,我们借用了sougou/workflow 的网络能力,仅几行简单的代码,就实现了CGraph对外提供http并发服务的功能。感谢workflow项目负责人的支持,希望这篇文章可以帮忙做点引流,哈哈。

因为白嫖的成本太小且收益太高,让我深深的爱上了这个活动。接下来有空的时候,还会考虑一些数据库、消息队列等三方项目的引入,通过共建,极大的扩展CGraph的适用领域。By the way,在这里提(dao)前(bi)预(jin)告(du)一下,百度大佬主导的基于CGraph的rpc项目,接下来的一年里应该也会和大家见面了,期待。

写在最后

回忆到现在,我的嘴角是带着笑意的。开始的那一刻,也没想到会有接下来的这些内容,只是工作中调库调的多了,单纯想写一个类似的东东,让自己练手,让大家能用起来。

image-1674885944013

聊聊接下来的规划吧。首先最想要做的,就是打通和python交互的生态。可以是cython,可以是ctypes,可能是rpc,也可以是其他的方式。总觉得这种框架,兼容了python生态,会有一个爆破式的跃迁,各种新的应用场景和领域,也会随之明了。

分布式的能力,也是一个当前的framework中基本的必备条件。后期我们可能会通过引入三方库的形式支持,期待您提供意见,最好是提供您可以合作的产品。我们继续碰瓷名项目之旅,哈哈。

还有就是调度性能的优化。在之前的对比中,我们已知,在简单图执行层面跟taskflow基本持平。在新的一年里,我们是希望可以通过一些思路,进行直接的超越。包括但不限于引入协程,或者是优化图分解方法等。

新的一年,希望可以接触到更多优秀的小伙伴,在工作之余一起做一些相关的努力,也希望可以有更多的落地项目可以被看到。希望大家健康平安,心情愉快吧,哈哈哈。

mmqrcode1602771241876

                                                          [2023.01.28 by Chunel]

推荐阅读


个人信息

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

image