帮忙看看我这种算法对么?

  • 11 replies
  • 1886 views
帮忙看看我这种算法对么?
« 于: 十一月 27, 2013, 06:06:14 pm »
前几天看到HP的一台机器支持8片NV卡,而华硕ESC4000G2支持4片我是这么想的: PCI3.0  16x 的速度大约是12GB/s 每个QPI总线总带宽=每秒传输次数(即QPI频率)×每次传输的有效数据(即16bit/8=2Byte)×双向,所以QPI频率为6.4GT/s的总带宽=6.4GT/s×2Byte×2=25.6GB/s 2Nvcard*12Gb=24GB正好大约是一个CPU的总带宽,所以华硕的ESC4000G2的双路带4卡的设计比较合理是么,而HP的双路带8卡的话,他的传输必须要等待是么,我只是知道一些皮毛,不知道我的的这种算法是否正确?希望懂的给个正解,谢谢了!

*

sisiy

  • *****
  • 214
    • 查看个人资料
(无标题)
« 回复 #1 于: 十一月 28, 2013, 10:57:05 am »
您的问题我们已经转给华硕产品部门,他们研究后会尽快回复您的。

另外,能否告知一下这款机器的型号,我们要查一下它的规格才能比较准确地回复您的问题

(无标题)
« 回复 #2 于: 十一月 28, 2013, 04:02:59 pm »
HP这款的机器我知道,因为考虑某些商业因素,华硕不便在任何场合评价友商的产品或技术。

在超算产品线运营方面,目前业界只有华硕一家是把超算作为单独产品类别进行管理,源于华硕坚持超算所要考量的技术要点有别于通用型服务器产品,从ma_ybiao独自进行底层数据带宽试算就足以看出某些技术考量点上的差异。

有关超算数据带宽方面,基本上涉及三个部分:1,PCIe运行带宽;2,CPU数据吞吐;3,RAM数据带宽
CPU和RAM的部分很容易从相关参数表中获取,PCIe运行带宽部分却很少有厂商专门去提及。

简单来讲,要判断一片并行计算卡或加速卡是否发挥出性能,除了与本身的并行代码有关之外,还与PCIe运行带宽有关。我们假设代码部分已经处于理想状态,那么PCIe运行带宽就至关重要,仍然以ma_ybiao假设的Intel CPU平台来讲,新一代IVB微架构CPU中已集成了PCIe控制器,以E5-2600v2来看,单个CPU可以提供总数为40个lanes的PCIe 3.0通道,2颗E5-2600v2一共可以提供80个PCIe 3.0 lanes,目前Tesla K20系列规格为PCIe 3.0 x16,也就是说要发挥K20理论性能,需要为每片K20提供16个PCIe 3.0 lanes,所以双路E5-2600v2一共可以原生支持5个K20(80除以16),所以至此可以很清晰的知道,超过5片K20之后的使用情景一定无法跑到全速。

要想让一台机器支持更多的卡片,实现起来非常容易,只要符合PCIe控制器的分组规范或通过串接更多的PCIe Switch就可以解决,但这样做的结果就是无法实现全速计算,当然如果计算数据量不足以到达数据带宽阀值,那么在应用上问题不大,当然全速计算还要考虑CPU吞吐及内存数据交换,以及某些高级编程技术,华硕研发数据表明,2颗IVB CPU架构下配合4片并行计算卡或加速卡是最佳的。

特别声明:
以上回应,仅限技术范畴内交流,旨在帮助用户了解更多的技术逻辑,华硕未以任何形式参与对任何第三方公司产品或技术的评价或攻击,并借此感谢用户对华硕超算产品的支持与关爱!

(无标题)
« 回复 #3 于: 十一月 29, 2013, 06:16:28 pm »
ma_ybiao您好:

这两天突发事件缠身,很抱歉现在才给您回答这个问题,见谅。

您的问题我将分为多个方面分楼回答,同时我的回答仅代表我个人观点,请您辩证地参考。所有我的回答仅限于讨论问题,并不表示推荐/不推荐具体厂商的具体产品。

首先,我要指出您文中的几点问题:

1:您在计算pci-e 带宽的时候计算的是单向的带宽,而您在计算QPI带宽的时候则是按照双向计算。考虑到pci-e和QPI都是全双工的设备,都能同时连续进行双向传输,所以您这样比较是不合适的。

2:QPI的带宽 不等于 “CPU的总带宽”,实际上很难界定什么是“CPU的总带宽”。

3:pci-e的带宽也并不和QPI带宽直接对接,具体的访问形式需要具体分析。

4:决定一个CPU搭配多少GPU,更多地是考虑一个CPU提供的原生pci-e lanes,其次有机箱空间,供电,散热方面的考虑,也有设计意图方面的考虑。

以下将依次与您讨论这些问题。


(无标题)
« 回复 #4 于: 十一月 29, 2013, 08:17:43 pm »
1:关于pci-e 的带宽和QPI的带宽计算

a)根据pci-e 的每一个lane,拥有两对不同方向的差分信号对,用于完成全双工的数据传输。在pci-e 3.0下,信号的频率是8Gbps,考虑到pci-e 3.0使用了效率更高128b130b编码替代了之前pci-e 1.0~2.0时代的8b10b编码,这使得pci-e 3.0的编码效率接近100%,也就是说每个lane,每方向理论可以得到接近1GB/S的速度。

在实际应用中,因为数据包确认,CRC,封包开销还有其他的影响,一般pci-e 3.0 @16X 能跑到12GB/S的单向速度,而pci-e 2.0 @16X 能跑到6GB/S的单向速度。

如果是双向传输,理论速度应该乘以2。

b)关于QPI,有两组,每组20lanes link,分别是不同的方向,并且接收和发射是可以同时进行的,是全双工的。这20个lanes每周期每个lane传输2bit的数据,每两个周期发射的80bit数据为一个flit,其中包含8bit的校验,8bit的link layer head和64bit的data。

假定一个运行在3.2GHz的QPI总线,其单向传输带宽为
3.2GHz  * 2 (double data rate,每周期每lane 2bit)
            * 20 (QPI有20个lanes)
            * (64/80)  (data bits/ flit bits,去除校验和link layer head开销)
            /8 (bits per byte,转换为字节)
            =12.8GB/S

如果考虑双向传输的速度,则为25.6GB/S,与您计算结果一致。
顺便说一下,GT/S是考虑过double data rate之后的,从数字上看,恰好是GHz的2倍。
即3.2GHz的QPI被标称为6.4GT/S。

c)最后考虑到我们讨论的平台,intel XEON E5 2600/2600 v2 的双路平台,那么此时pci-e和 QPI的实际情况为(考虑该系列中高档型号CPU的参数):

pci-e :每个CPU 最多可以提供40lanes pci-e 3.0的通道,这40个lanes是CPU直接提供的,其pci-e 控制器连接在CPU内部的ring bus的一个stop上。如果南桥(C600系列芯片组)仅通过DMI总线连接,则这40个lanes都可以直接使用;如果有4lanes连接到南桥芯片以扩展CPU和芯片组的通信带宽,那么最多有36 lanes可用。

对于双路系统,如前面讨论的ASUS ESC4000 G2系统,一共提供了9个pci-e 16X的插槽,全部运行在pci-e 3.0的速度上,其中有8个插槽是全高的,可以运行为16x*4或者8x*8的模式,考虑到一般的计算卡都是双槽位的,所以推荐使用4卡模式,所有的卡都跑在pci-e 3.0@16X的原生全速模式,最后一个卡是半高的运行在8x模式,留给SAS扩展卡使用。

从中可以分析出,不接C600的那个CPU,贡献出来了全部的40lanes,其中32lanes给GPU使用,8lanes给SAS卡使用,而接C600那个CPU,贡献出来了32lanes给GPU使用,其他的8个lanes可能连接了芯片组或者其他设备。

QPI:根据intel官网的参数,E5 2600/2600 v2都支持最高 8GT/s(4GHz)的QPI总线,此时QPI总线的双向合并计算的带宽是4.0*2*20*(64/80)*2/8=32GB/s。

但值得注意的是,E5 2600/2600 v2系列的CPU,每个CPU支持两个独立的QPI link,这两个QPI link通过QPI Agent 连接在CPU内部的 ring bus stop上。以及,和上一代XEON 5600 CPU不同的是,此时的QPI总线完全用于CPU之间的互联,而无需再去连接芯片组的北桥芯片。也就是说,此时两个CPU之间有两个4.0 GHz频率的QPI总线互联,双向合并带宽为32*2=64GB/s。

对比上一代的XEON 5600家族CPU配合5520芯片组的双路系统,每个CPU虽然也有两个QPI总线(比E5 2600家族频率低),但是只有一条QPI总线用于CPU之间互联,另外的一条QPI总线用于和5520芯片组互联,5520芯片组提供了pci-e 2.0速度的 36 lanes。换句话说,上一代的pci-e通道是北桥提供的,并且要占据一个QPI link,而这一代E5家族,速率翻倍通道数提升的pci-e总线是CPU直接提供的,而同时,速率提升的两组QPI link全部用来进行CPU之间的通信。这样,无论是pci-e 的速度还是QPI CPU互联之间的速度,都是翻倍以上的提升,这是一个显著的改进。

最后,您可能会发现,此时用于GPU的32个lanes的理论双向合并带宽为64GB/S,两个QPI link的双向合并带宽也为64GB/s,但需要指出的是,这并不能直接说是某种“匹配”,要根据具体的使用情况具体讨论,详见后面的楼层。

(无标题)
« 回复 #5 于: 十一月 29, 2013, 08:22:06 pm »

(无标题)
« 回复 #6 于: 十一月 29, 2013, 08:37:45 pm »
2:您前文提出“CPU的总带宽”,但这实际上是难以界定的。

只要有数据传输的地方,就有带宽,但是对于CPU而言,有多个相关的带宽。

比如:
a)CPU集成的内存控制器的带宽
b)CPU集成的pci-e总线的带宽
c)CPU集成的QPI link的带宽
d)CPU内部数据传输总线的带宽,E5 2600/2600v2这里是内部的ring bus带宽。
e)CPU内部各级cache的带宽/合并带宽
等等

这里我们不讨论e和其他没有提及的部分的带宽,同时假定d总是够用的,不考虑CPU其他部分对ring bus的争抢,不考虑ring bus的其他调度是否有影响,考虑到这是CPU内部的高速总线,这一假定一般是合理的。

让我们回到E5 2600/2600v2的双路系统上来,此时前三个带宽分别为:

a)E5 2600 支持4通道的DDR3 1600,其带宽为51.2GB/s
     E5 2600v2 升级为 4通道 DDR3 1866,其带宽为接近60GB/s
     这里的带宽是读+写的,并没有像pci-e或者QPI那样双向是分开的。

b)前面已经阐述,每个E5 2600/2600 v2的CPU可以提供最多40个lanes,其中一般有32 lanes给GPU使用。那么pci-e 3.0 @32 lanes 的双向合并带宽为64GB/s,两个CPU都算上的话,是128GB/s(每双路CPU系统)。

c)这个前面也计算过了,两个E5 2600/2600 v2之间的QPI的双向合并带宽是 64GB/s。

(无标题)
« 回复 #7 于: 十一月 29, 2013, 09:23:07 pm »
3:在前面的分析以及各个不同途径带宽的分析下,您应该可以理解为什么我说pci-e的带宽和QPI的带宽并不能直接相比较,并以此判断是否匹配。

前面说过的pci-e控制器,QPI link的控制器和内存控制器在E5 2600/2600 v2上都挂在CPU 内部的ring bus总线上,我们总是假定ring bus不成为瓶颈,那么分析在传输过程中带宽是否匹配就需要考虑不同的传输途径下,带宽是否匹配(这里不考虑软件方面的问题,如API效率等)。

依然是前面的双路系统,先考虑一个CPU的情况,此时无需考虑QPI的影响。

考虑2个GPU都跑在pci-e 3.0 @16X的原生模式下(这也是ESC 4000 G2的推荐模式),此时GPU如果是单向传输数据到内存,那么pci-e 总线假定是单方向跑满的,那么是32GB/s,而内存带宽为50GB/s以上,此时pci-e总线可以跑满,内存总线还有富余。

如果是两个GPU双向传输数据,并且是双向跑满的,那么合并带宽是32GB/s读+32GB/s写=64GB/s 读+写,而内存总带宽为51.2GB/s或60GB/s,这略低于pci-e 用到的带宽。

如果是两个GPU之间点对点传输,那么取决于pci-e控制器的情况,无法深入讨论。

如果是配置为8X*4的形式,那么前面计算的pci-e总线总体带宽 VS 内存控制器带宽的结论是不变的,但是每个GPU获得的带宽将减半。

下来讨论更加复杂的双路CPU情况,此时需要考虑两个CPU通信。
双路的两枚CPU 分别记为0# CPU和1# CPU。

现在考虑0# CPU下辖的pci-e上的GPU的通信情况。
a)与本地内存(0# CPU的内存控制器下的内存)通信——这就是前面讨论过的情况。

b)与QPI总线通信,考虑到双QPI link双向合并带宽也为64GB/s,QPI link不成为瓶颈,但是
    b.1)如果通过QPI传输的数据来源于1# CPU的内存呢,那么内存带宽将成为瓶颈。
    b.2)如果通过QPI传输的数据来源于1# CPU的pci-e上的GPU,那么如果1# CPU上的pci-e总线如果能够通过ring bus直接将数据传递给QPI Agent并传输,那么将无瓶颈;如果1# CPU做不到这一点,而是需要将数据先传递到内存,再通过QPI传输,那么不仅内存带宽会造成带宽瓶颈,1# CPU一端还会因为先要将数据copy回内存,而产生延迟等。
    b.3)如果通过QPI传输的数据同时来源于1# CPU的内存和pci-e上的GPU,那么可以看作是前两种情况的组合。

c)如果0# CPU上的pci-e 上的GPU的数据同时来源于本地内存和QPI,那么如果两者可以同时向pci-e传输数据,则能比较容易地将0# CPU上的pci-e跑满;如果不能,则需要具体的传输路径考虑瓶颈和延迟。

如果两边的GPU同时考虑,问题将进一步复杂化。

①:如果两边的GPU都只访问自己的本地内存,这个和前面讨论一样。
②:如果两边的GPU都密集地访问一个CPU上的内存,那么内存带宽将成为瓶颈。
③:如果两边的GPU都密集地访问对方的CPU上的内存,那么QPI link将成为瓶颈。
④:如果两边的GPU都密集地需要访问对方显存的内容,此时QPI是瓶颈,并且还可能因为需要先转到内存产生更多的开销。
⑤:其他的混合形式暂不一一列举分析了。

综上所述,只有得到具体的访问方式,才能评价此时的瓶颈在哪里。

(无标题)
« 回复 #8 于: 十一月 29, 2013, 09:32:03 pm »
ma_ybiao您好:

这两天突发事件缠身,很抱歉现在才给您回答这个问题,见谅。


4:在前面详细讨论了大量的带宽分析之后,让我们抛弃这些繁杂的数据,回到最简单最直接的角度重新考虑这个问题。

OK,为什么双路机型是4GPU,而不是8GPU?其实没那么复杂。

每个GPU 都是pci-e 3.0@16X的,要满足这个要求,双路 E5 2600家族,一共也就能提供最多80 lanes,考虑到不能跨CPU组合,每个CPU 40lanes也就能拿出来32lanes给GPU用,从而是2个完整的16X 原生插槽。反正终归总是为了满足GPU的需求而已。

然后围绕着这个目标设计就行了,没那么多理由,空间,散热,供电,爱啥啥都是人设计的。

(无标题)
« 回复 #9 于: 十一月 29, 2013, 09:58:19 pm »
5:反思

前面说过这一切都是设计意图决定的,难道真的不能在2 way系统中设计8GPU么?

这个显然是可以的,如果我们的设计意图是尽量增加每个节点的GPU/加速器设备密度,并且愿意承受由此带来的每个GPU的pci-e可用带宽缩减,那么不要说8 GPU,16GPU也能设计出来,大不了GPU跑在pci-e 4X上么,intel的CPU提供的pci-e是允许这样拆分的,或者多上一些switch芯片也可以。

两者的不同在于,直接拆分,每个GPU都是原生的通道,但是lanes是定死的,哪怕其他所有GPU都闲着不干活,干活的GPU也不能得到更多的带宽。

而后者虽然变成了非原生的lanes,延迟会增加一些,但是例如一个原生的16 lanes通过switch变成两个16 lanes的端口,那么在这两个16 lanes 的端口上的GPU,如果交错使用pci-e ,那么都能享受到接近真正16 lanes的带宽(当然同时用显然还是相当于两个8 lanes)

以及,市面上真的出现了这样的产品,真的不怕前面分析的一大堆瓶颈么?

这其实需要从GPU的数据访问说起。

GPU的global memory,对于GPU核心而言,已经属于长延迟,低速度的大容量存储器了,但是单卡global memory动辄接近100~200GB/s的带宽,依然远远高于前面说过的pci-e带宽,内存带宽和QPI带宽。

同时,任何一个离开GPU卡本地的访问都需要走pci-e总线,这是一个延迟又比global memory长得多的访问途径,如果还要加上走QPI去访问另外的CPU,则情况更甚。

所以,如果真的到了需要密集访问内存,或者需要密集通过QPI访问另外的CPU的资源的时候,其实这个GPU已经没什么执行效率了,都被卡在各种低速的访存上了。

所以,合适的使用方法是,尽量安排GPU访问自己的显存(以及缓冲到片上的各种cache上),只将一些边界的需要交换的数据通过pci-e,内存或者QPI予以传递,并且尽量安排用计算来掩盖边界数据的传输,这样才能保证较高的效率。

所以,最终的结论居然是,楼主纠结的参数,实际上可能没有他想象的那么重要;而某个应用下如果真的这些参数极端重要,那么该应用本身的GPU效率可能已经浮云了。不同设计意图的产品,需要在了解其特性和自身算法需求之后,综合考虑。而厂家设计产品需要有通用性,不可能设计极为极端的产品,4 GPU@16x or 8GPU@8x 其实都还算是比较适中的选择。

写了数千字,最后得到这样一个看上去似乎很无所谓的结论,不知楼主看到以后,是不是会觉得很意外?

最后,欢迎ma_ybiao 莅临 GPU world论坛@吉浦迅科技,祝您在论坛过的欢乐~

(无标题)
« 回复 #10 于: 十二月 02, 2013, 08:20:47 pm »
您的问题我们已经转给华硕产品部门,他们研究后会尽快回复您的。

另外,能否告知一下这款机器的型号,我 ...

hp ProLiant SL270s Gen8

*

sisiy

  • *****
  • 214
    • 查看个人资料
(无标题)
« 回复 #11 于: 十二月 03, 2013, 12:27:42 pm »
hp ProLiant SL270s Gen8

感谢您提供型号。

不知道我们工程师和华硕的工程师是否已经回答了您的问题。请常来