陈怀临时间–浅谈网络处理器的编译器设计方法

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




(25个打分, 平均:4.28 / 5)

雁过留声

“陈怀临时间–浅谈网络处理器的编译器设计方法”有27个回复

  1. 匿名 于 2008-11-26 3:05 上午

    听完了,收获不少。

    一个是,沿用GCC的front-end, 我觉的是个好主意

    二个是,关于那个ABI的,原来那些调用规定之类的玩意都是属于ABI的范畴···,今天刚知道有这么个东西

  2. 陈怀临 于 2008-11-26 7:18 上午

    读者同学们,真不厚道:-)。这个竟然没得全A。太让我沮丧了。我不能拿gcc backend来谈细节吧?或者对NPU的compiler设计不敢兴趣?

  3. gg 于 2008-11-26 8:44 上午

    谢所长两周啊,德高望重啊。。这个比较搞。。。

    complier感觉大家应该是都没有实际经验吧,都很好奇,但是没有具体的工程、开发经验,所以。。。嘎嘎

  4. getmoon 于 2008-12-03 11:18 下午

    陈教授讲座很精彩,我对编译器这块了解不深。04年我们刚开始接触ixp2400的时候,开始也对微码有恐惧感,寄希望于当时intel提供的c编译器,可是后来发现c编译出来的性能是在太惨了。 只好放弃,选择微码。不过intel提供的一些已经封装好的的micro使用起来也是非常方便的。

    但是网络处理器毕竟还是一个很专用的东西。需要根据数据包的处理做相应的优化和特殊设置,微码编码还不可缺少,只有等c编译出来的可执行代码的性能不是关键问题之后。才能完全解决性能和代码可读性强 ,可调试性强这对矛盾体。

  5. 陈怀临 于 2008-12-04 7:22 上午

    是的。对NP的最佳利用应该是混合编程。对需要非常高效率的,不排除手工编汇编。在没有编译器,assembler等的条件下,你们也一定要尽量遵循一些寄存器使用约定,从而为代码维护打下良好的基础。Intel的ixp编译器,如对那些ME的并行thread代码分布等,基本上不现实。并行编译如果能够真正在工业界实用化,系统软件将会是巨大的飞跃。我个人认为短时间内不可能。

  6. softmaster 于 2008-12-04 8:50 下午

    有一个问题始终没想通,请教各位专家一下。
    对于IXP2400这一类NP而言,的确是很少见到有用C语言写代码的。但是我们最近做的一个项目用的一块NP是用C语言来写代码的。而且具有比2400更高的性能。
    两者的结构还是有一点不同。2400有8个微引擎,并且每个微引擎里面有8个线程。另外一块NP目前用了16个微引擎,每个微引擎都是单线程的。
    能否这样理解,对并行多线程的NP进行C语言编程现在还不现实。但对单线程的NP进行C语言编程是可行的。
    如果这样的话,我们可以通过增加微引擎的个数,而不是通过增加微引擎的并行多线程能力,来大大降低软件的复杂度。

  7. 陈怀临 于 2008-12-05 8:23 下午

    你的这个问题比较复杂。除了ME自己的clock能否上得去,许多事情的关键就是芯片的local bus的竞争问题能否解决好。如ixp2400和28xx系列,DRAM是装payload。SRAM是header。hardware thread再多,local bus的clock和capacity上不去,没有意义。打个比方:8个宝马车,牛不牛?确实很牛。但都开在一个真正的乡村牛道上,牛说怪宝马还是怪牛道?:–)

  8. 陈怀临 于 2008-12-06 7:39 上午

    在7里面没有直接回答6的问题。关于多核系统复杂性方面,我个人建议如下:用最简单的方法做最复杂的逻辑。把数据结构相关性考虑清楚。使得锁的粒度最小化。这是重中之重。

  9. 黄岩 于 2008-12-13 6:41 上午

    下面我来尝试探讨第6楼的问题,我理解softmaster提出的问题是:
    (1)为何见到用C语言编写NP代码的?
    (2)C语言编译器还不成熟、不实用,主要原因在于NP的编程模型是“并行多线程”的,对吗?
    (3)可否通过“增加微引擎的个数”来解决这个问题?

    第一个问题,为何见到用C语言编写NP代码的?

    我认为现在NP的C语言编译器还不成熟,还不能实用。相对于汇编语言来说,高级语言的主要优点是:(a)编程效率高,开发生产率高;(b)代码可移植。缺点是:运行效率低。对于NP来说,C语言编译器的优点并不明显,缺点却特别突出。

    先说编程效率。NP上面运行的代码量并不大,典型NP的代码空间是几K到几十K条指令,也就是一个产品的NP代码不会特别多。一般高端路由器产品,NP代码总量也不过几百K条指令,这个规模的程序,用汇编语言也可以完成,障碍不大。

    插一点题外话。NP开发的难度不是由于代码量大,而在于对人员的知识和能力要求高。例如,NP的开发人员需即要能够深入理解NP的硬件结构,要熟练掌握汇编语言开发,还要理解网络协议报文的处理流程(例如要掌握MPLS的工作原理),而且还有懂一点硬件知识(至少要会用示波器)。这样的人不太好找。这一点与很多其他程序开发不同。

    再谈可移植性。NP程序几乎天生不具有可移植性,即便用高级语言也不能移植。由于目前各个厂商之间的NP的结构几乎完全不同(试比较IXP2xxx、X11、EZChip NP2/3),NP程序又是跟芯片紧密耦合在一起的,因为必须利用芯片提供的各种硬件资源(如查表、HASH、mem IO等)才能够提高效率。甚至一个同一个厂商的不同型号的NP之间,程序的可移植性都很差。

    最后说运行效率。NP程序的运行主要是由报文触发的,收到了报文才运行。虽然NP的代码空间有几K到几十K指令,但并不是说对于每个报文,都能够用几十K代码去处理。一般来说,NP只允许对每个报文运行几十到几百条指令,超过这个数量,就无法达到“线速处理”这个硬指标了。例如:某型号NP有8个微引擎,核心运行速度是600M,并且每周期运行一条指令,又假设该NP有一个2.5G POS接口,全是最小报文的测试情况下,报文流入NP的速度大约是8M pps(packet per second),那么对于一个报文来说,允许每个微引擎的运行的处理指令最多是:600M / 8M,大约为70几条,8个微引擎加起来,在指令分配非常均衡的情况下,最多600条指令。以上都是按照理想情况考虑的,如果再去掉跳转、IO等待、ME之间处理能力分配不均衡等因素,那么实际对每个报文允许的处理指令可能也就是300条左右。在要求的线速处理路径上,如何用这300条指令来完成所有的业务处理,是需要仔细计算的。几乎不能容忍高级语言编译器再浪费一些指令。

    由此可见,也许在未来的很长一段时间内,我们还要用汇编语言来编NP程序。

    下面把第二个问题和第三个问题合并到一起分析。NP的的编译器的确还不成熟,但是主要不是因为“多线程”。

    对多数硬件支持的多线程芯片(CPU、NPU)来说,是由几套寄存器上下文共享一个ALU处理逻辑,在软件看来,就像是芯片里面有几个硬的“核”一样,没什么大分别。因此“多线程”也不会显著增加编译器的设计难度。

    下面尝试分析一下多线程和大规模多核两种不同的NP设计思路。

    芯片支持的多线程和多核的目标都是:充分利用硅片面积来提高单芯片的处理性能。但是方法不同。

    多线程的依据是:现在CPU/NPU的核心速度很快,但是DRAM的访问速度很慢(注1),因此很多时候,快速运行的CPU/NPU核心不得不等待内存访问完成,浪费了大量的处理能力。解决办法是,为一套运算部件多配几套寄存器,每套寄存器都保存一个线程上下文,当一个线程访问外部内存不得不等待的时候,就运行另外一个线程。这样运算部件的利用提高了。一般来说,多线程CPU/NPU的的每个核都比较复杂,运行频率也比较高,如果频率低于内存访问时间,多线程就没有多大意思了。

    对多线程来说,虽然运算部件的利用率较高,但是每套寄存器都会占用一定的面积,而且同时只能有一套寄存器处于运行状态,另外几套都是处在等待状态,还是有浪费。大规模多核NPU/CPU(注2)的设计者思路就不同,他们在芯片里面造很多个简单的核,每个核的频率都不高,占用面积也比较小,每个时刻每个核都在运行,争取让每个晶体管都工作起来。大规模多核芯片会尽可能用比较简单的、低成本的方法把这些核组织起来。NP的报文驱动的应用模式,恰好为组织这些核提供了方便,Xelerated和EZchip都巧妙的利用了这一点。

    多线程和大规模多核那种设计方法更好,现在似乎还没有绝对公认的结论。但我估计,未来在NP领域大规模多核会越来越多。

    (结束)

    注1: 虽然现在DDR3看起来速度已经达到了上GHz的级别,但是这是假象,只有访问连续的地址单元才能够达到这个速度。如果访问的地址单元不连续,则DRAM的瓶颈在于其tRC这个参数,一般只有几十纳秒。
    注2:如Tilera的Tile64、Xelerated X10q/11、EZChip NP1c/2/3等。

    —-
    http://china-router.spaces.live.com
    e=mail: mphyatyh yeah {dot} net

  10. 黄岩 于 2008-12-13 6:43 上午

    更正:
    (1)为何见到用C语言编写NP代码的?

    应为:
    (1)为何很少见到用C语言编写NP代码的?

  11. 莲花木匠 于 2008-12-13 10:02 下午

    分析的很棒。

    NP的运行效率固然是首位,但是面对业务、产品的多样性、复杂性,软件建立一个平台是必然趋势啊。

    对于不同设计理念的NP(CPU/NPU)必然各有优缺点,但是对于软件建模、上层应用肯定要趋于一体化,所以移植性、平台化也在情理之中。完全可移植那也是不可能,中间少不了硬件适配层了。目前正火的多核处理器也算是一个转折点了。

    ---多线程和大规模多核那种设计方法更好,现在似乎还没有绝对公认的结论。但我估计,未来在NP领域大规模多核会越来越多。

    ---编译器的设计方法也会越来越好:)

  12. Fake-Einstein 于 2008-12-14 3:33 上午

    Tile64这个东西我一直对其表示质疑,把它看作是NP的化,他根本无法和Xelerated及EZChip等厂家比拼,主要问题是集成度和接口容量不够,空有几个核在那里撑着,再说什么总线如何如何其实都意义不大了,要说他核多,X11比他更多,X11的总线没有点特殊设计也玩不转这么多Processor吧。就更不要说和NP1/2/3比了…
    把它看成通用多核处理器吧,又实在不知怎么用,那么小的一个核能量实在太有限了,L2Cache又是独立的,处理共享数据怎么得了啊。跑Linux时的性能实在是不敢恭维。
    所以怎么看怎么像一个实验室里出来的产品,跟那两个厂家没法比的

  13. 陈怀临 于 2008-12-14 5:42 下午

    抽空把黄岩的评论读了一下。人才。我现在非常好奇。他说不是华为的,估计也不是ZTE的。否则我觉得有他ZTE就能把华为数据通信打趴下!

    神州大地藏龙卧虎呀。。。。。。

    当然,黄贤弟的评论,从我的个人角度读后的猜测:
    ×不像是第一线做技术的。如没有参与设计过高端芯片。但感觉知识量确实很大。
    ×感觉像一个公司里做高层技术架构分析,战略规划的。
    ×是EE出身:–)

    总之,是个高手:-)。说良心话,与华为数通的CTO都有一拼:-)

    请多来指教,并注册发表专题分析文章。

    另外,愚兄我个人的一些文字可参阅:
    http://www.tektalk.cn/?p=3103

    请多批评:-)

  14. 黄岩 于 2008-12-15 6:04 上午

    To Fake-Einstein:

    Tile64的性能还是不错的,它适合做一些整数和逻辑运算量特别大的应用,以及一些定点DSP的事情,例如:IPTV和手机电视的视频数据转换、电话会议等。如果用在网络设备上,他适合用来做一些报文深度处理任务,例如:企业网的防火墙、运营商的DPI设备等。我做过一些简单测试,用来作MD5计算的时候,速度是普通Intel 2.4G双核X86的6倍,内存访问带宽是Intel 2.4G双核的2倍,用来作简单的IPv4路由转发,可以达到单向10G以太网小包,这个性能是普通X86不能比的。与X11和EZchip相比,也许Cisco的SPP、QFP跟Tile64更相像。

    Fake-Einstein说的对,Tile64也许不能算是NP,好像Tilera自己也没有说它是NP。他的主要竞争对手是Cavium、RMI,还有TI的DSP。其实我觉得,Tile64用来做google的服务器,还是很合适的,搜索引擎就是整数计算密集型的应用,他功耗很低(30w),能帮google节约大笔电费、空调费。做web服务器也不错,作网络游戏的后台处理也很好,还可以推荐给国家安全局做解密机:)我觉得这个芯片完全可以做成刀片服务器,在某些通用特定领域与Sun的T2、IBM的cell processor一争高下。只不过现在Tilera公司太小了,还没有来的及去开发这些市场。

    插一点题外话,究竟什么芯片才能算是是NPU,也许现在也没有一个公认的标准。我觉得,如果如果把所有能够作报文处理的芯片都放到一起,作一个分类比较,按照他们的处理能力从大到小,灵活性从小到大作一个排列,那么BRCM和MRVL的以太网交换芯片排在最前面,X86之类的通用CPU芯片就排在最后面,中间的就是NP。但是NP和CPU之间的界线究竟应该在哪里划分,这个就见仁见智了。BRCM把自己的SiByte系列多核叫做NP,其实是比较典型的多核CPU,只是集成了一些以太口和SPI4接口而已。Linley Group关于NP的市场研究报告里面,把Wintegra的Winpath系列芯片也成为NP,但是与其结构相近的Freescale的PPC却没有被当作NP。同样道理,NP与ASIC之间的界线,也是引人而异的。

    Fake-Einstein说的很对,X11的结构很特别,非常巧妙。只是我手上拿到的资料是签了NDA的,不能透露更多细节。EZChip的设计思路更加中规中矩一些。与这两款芯片相比,Intel的IXP2xxx系列,更接近CPU一些,处理能力低,但灵活性强。

    To 陈怀临:

    谢谢陈先生鼓励,我会继续努力:)我看过陈先生的一些技术著作,收益颇多。

    我在中国西部一家小企业工作,我们公司跟一般的沿海乡镇企业规模差不多。我是其中一名普通的技术人员,没有任何头衔,以前是编程序的,现在是编技术文档的。我自己从没想过去跟华为数通的CTO去“拼”,在华为,像我这样的技术人员多的数不胜数,只是华为特别忙,他们没有时间来这里参与讨论罢了。这一点,我还是有自知之明的:)

    我们大家都拿出自己的休息时间,在这里参与一些技术问题的讨论,每个人都希望能够在tektalk学到一些东西,能搞清楚一些自己以前不明白的问题,也希望自己的发言能够对别人有用,也希望能够得到别人的鼓励,更希望这个论坛能够越办越好。我就是抱着这个态度来参加讨论的。所以,我们在现实生活中的身份并不重要,别在这个问题上浪费时间了。陈先生以前写了很多很好的技术文章,使我们得以透过烟花缭乱的表象,看清楚问题的本质,这方面我们要向您学习。

    对您的“对华为系统软件的战略思考-华为集成”这篇文章,我写的评论言语颇为尖刻,望您海涵。不过说实话,我觉得您的这个系列文章,对华为的品牌形象还是有一些负面影响的,特别是对那些国内运营商的领导们,他们手握采购大权,并且其中有一少部分人自己没有技术判断能力,本来这些人就对Cisco、Juniper、Alcatel-lucent等洋品牌盲目崇拜,看了您的文章,更是给他们的偏见提供了有力的佐证。

    另外,我昨天在tektalk上注册了账号,并且上传了一篇技术随笔“宽带路由器杂谈”,已经提交审查了,但现在还没有刊登出来。麻烦您帮忙。如果审查有什么问题,麻烦回个邮件(mphyatyh yeah net),我好尽快改。

  15. 黄岩 于 2008-12-15 6:09 上午

    更正:
    收益颇多。
    应为:
    受益颇多:)

    我的电子邮件:mphyatyh {at} yeah {dot} net

  16. Dasha 于 2008-12-15 9:02 上午

    这是我看见的最好玩得贴子。如果黄盐所说句句属实,那也忒不厚道了,这不明摆着抽别人脸吗。

  17. Fake-Einstein 于 2008-12-15 9:25 上午

    To 黄岩
    关于Tile64的性能,您列出的数据其实算不上好,对比您提到的两款多核处理器,还有相当大的差距,而要和TI的DSP拼,可能就更困难一些了。要知道一款芯片能不能用,不能光片面的看他的某些指标,他所处的生态系统和面对的竞争对手可能早已经决定了他的命运。现在的设备厂商眼光其实都还是很尖的,一款芯片能不能用,好不好用,三招五式以后基本也就看个大概了。而且在通信领域和X86比拼性能实在是太没追求,X86都是被人当靶子使的,其内存吞吐率,处理能力早已为人所诟病。Intel之所以能在服务器领域一枝独秀靠得其实即不是性能,也不是功耗。市场上性能功耗做的的比X86好的处理器有很多,哪个又敢和Intel一拼高下。
    一款芯片适合做什么不能光凭其某一方面的优点下结论,全面的审视其各方面的优缺点后你可能会得出完全相反的结论,这是我给你的一点忠告!

    从另一个角度看中科院那个龙芯四核似乎和Tilera有点像近亲,看到他就好像又回到了并行机时代…非要搞得穿纸带打孔才算是高科技,唉…

  18. 陈怀临 于 2010-03-05 10:16 下午

    MT,小刘,小强最近谈了许多NPU,ASIC等事情。这是我以前YY录过的一个关于如何做NP的编译器的东东。愿意被我的声音pollute的,大家随意:-)。不勉强:-)

  19. Multithreaded 于 2010-03-06 8:27 上午

    Saturday is very busy for the kids. I will reply later. This is an exiting topic and wew should let it rolling.

    By the way, can you put up slide deck instead of voice?

  20. Multithreaded 于 2010-03-07 4:49 下午

    #6 涉及到了一个很重要的概念, multithreading vs. multi-core.

    多线程是指同一个核上实现多个逻辑核,以共享同一个物理资源。它对网络的数据面应用非常有用,因为L2/L3的fastpath通常是memory-bound的应用而不是cpu-bound的应用。Multithreading can be used to hide memory latency since most of times the CPU is idle.

    Howwever if we say multi-core programming is hard, multi-threading is harder, and multi-core plus multi-threading is the hardest.

    The 16 NPU you mentioned probably is Cavium one. Since there is a thin Linux running on the top of each Cavium NPU, programming is relative easier than Intel IXP-2400.

    The Cavium is good at L3/L4 about applications and IXP’s is good for L2/L3 ones. If you really want to compare the performance, you should compare Cavium one with Intel IXP-2800 using one L3 benchmark such as IPv4 forwarding.

  21. Multithreaded 于 2010-03-07 4:59 下午

    #17, 从另一个角度看中科院那个龙芯四核似乎和Tilera有点像近亲,看到他就好像又回到了并行机时代…非要搞得穿纸带打孔才算是高科技,唉…

    从哪得到的这个消息? 如果是真的,龙芯四核危险啊!

    Tilera 是一个用于处理DSP的多核,再DSP领域里会用一些应用。把它做通用多核的体系结构是万万不行的。

    在有一个Tilera和SUIF compiler绑的太紧,还不到大规摸应用的火候。

  22. 1help1 于 2010-03-07 7:14 下午

    1年多以后再听同样的讲座,会发现有不同的感受.实际上,在听别人讲座的时候,是和自己的知识体系的融合的过程.随着自己知识体系的发展,可以有更多的融合.

    无论是CPU的architecuture设计,还是compiler设计再或者是OS的设计,都需要通盘来考虑.比方说,CPU的结构设计中,怎么样能让编译器弄的舒服,让OS跑的舒服. 编译器的设计者需要考虑到CPU的体系结构,比如流水线.怎么样根这个CPU的微结构特点来榨干性能.而OS的设计者同样需要考虑编译器和CPU结构,怎么去设计exception handler,让interrupt的处理时节能足够的短(这个就需要CPU的设计者能提供一些机制最好了).

    其实我想说的就是, CPU的architecture设计者,COMPILER设计者和OS的设计者 要有着跨领域的经验,通盘来考虑这几者的协作.这样才能设计出高性能的系统. 才不会出现每一个环节单独看起来都不错,但是整个系统就是会出现尺码不匹配的情况.

  23. Multithreaded 于 2010-03-13 8:29 下午

    〉其实我想说的就是, CPU的architecture设计者,COMPILER设计者和OS的设计者 要有着跨领域的经验,通盘来考虑这几者的协作.这样才能设计出高性能的系统. 才不会出现每一个环节单独看起来都不错,但是整个系统就是会出现尺码不匹配的情况.

    实际情况是很难做到这点, 尤其是大公司里,不同的团队负责不同的模块,从政治上讲,很难协调。

  24. Multithreaded 于 2010-03-13 8:37 下午

    〉对多数硬件支持的多线程芯片(CPU、NPU)来说,是由几套寄存器上下文共享一个ALU处理逻辑,在软件看来,就像是芯片里面有几个硬的“核”一样,没什么大分别。因此“多线程”也不会显著增加编译器的设计难度。

    恰恰相反,多线程大大增加编译器的设计难度。 据个例子吧。

    Give two statements:

    x = a[i] ;
    y = x + 1;

    On a non-blocking multi-threadec system, compiler should generate the following code;

    x = READ(&a[i],SRAM) //! assume a is in SRAM;
    thread_switch(); //! End of the current thread

    y = x + 1;

    From this example, one can see adding thread_switch instruction at the righr place is the key to making program running correctly.

    Believe me this problem is NP-complete :-(

  25. 陈怀临 于 2010-03-13 8:59 下午

    MT,你能否写一篇AMD最新的12个core的芯片的一个文章和相应的评论?我没有时间写。而且我觉得你比我跟合适。

  26. silverhawk 于 2012-04-27 1:05 下午

    我怎么打不开连接?首席给个tudou的连接吧,我用了几个浏览器都不行,flash不能load

  27. Ma Ling 于 2012-05-02 6:56 上午

    To 24
    由于运行状态下Cache Miss 随机性非常强,现代多线程CPU会自行控制线程的”切换”,这种”切换”对于软件透明。现在的多线程CPU也大都由这粗粒度的调度策略转向SMT。