JPEG 在 GPU 上压缩性能瓶颈分析

目前市面主流用于服务器进行计算的Tesla系列GPU,主要有K80,P4,P40,P100,M40,这些卡性能指标有着不同差异导致成本上也相差很多。

鉴于AI是当下最火的技术方向,GPU加速运算在这方面又有天然的优势,所以官方在介绍其性能差异时主要针对AI各个计算框架来展示其加速比。

而针对于图像压缩处理这样的场景来说,其计算量较AI又有着很大的差异。为此有必要针对于图像压缩处理这样的场景进行性能分析。

图像压缩流程

首先来看我们的应用的计算过程,部分代码在CPU上运行,部分代码在GPU上运行。在CPU和GPU上的数据需要通过PCIE在主存和显存之间进行交换。

数据交换阶段

以三通道的JPEG图像resize为例,从读取图片数据,解码数据,resize图像,编码图像,拼接图像的完整时序如下图所示:

进入GPU的第一步是图像huffman解码后的数据拷贝到显存,而拷贝是通过PCIE Bus来进行的。那么PCIE bus的bandwidth以及多卡时的物理拓扑就将决定数据拷贝延迟。

就目前我们配置的M40标准设备而言,GPU不直接与CPU相连,而是每两卡挂在pcie switch上,pcie switch再连接到CPU,”PLX Technology, Inc. PEX 8747 48-Lane, 5-Port PCI Express Gen 3 (8.0 GT/s)”

每个PEX 8747共五个端口,其中一个x16端口是和CPU做连接,剩下的四个端口用于连接GPU,我们拿到的设备每两卡挂一个switch,每卡的lane width为x16,理论传输带宽为16GB/s。 当配置4卡时,每卡的lane width为x8,理论传输带宽为8GB/s。switch与cpu之间的lane width为x16。

那么如果同时两卡或四卡有数据在CPU与GPU之间进行传输时。那么16GB/s的带宽将被共享。鉴于图片压缩这样的应用场景各个GPU之间无数据共享的需求,那么无需配置PCIE switch。

而采样GPU直连CPU这样的拓扑结构每张GPU能独占16GB/s的pcie传输带宽。M40/P4 实际测试单卡传输带宽双向12GB/s。而多卡共同传输时P4带宽下降不显著。

M40标准设备物理拓扑:

       GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7    CPU Affinity
GPU0     X      PIX     PHB     PHB     SOC     SOC     SOC     SOC     0-13,28-41
GPU1    PIX      X      PHB     PHB     SOC     SOC     SOC     SOC     0-13,28-41
GPU2    PHB     PHB      X      PIX     SOC     SOC     SOC     SOC     0-13,28-41
GPU3    PHB     PHB     PIX      X      SOC     SOC     SOC     SOC     0-13,28-41
GPU4    SOC     SOC     SOC     SOC      X      PIX     PHB     PHB     14-27,42-55
GPU5    SOC     SOC     SOC     SOC     PIX      X      PHB     PHB     14-27,42-55
GPU6    SOC     SOC     SOC     SOC     PHB     PHB      X      PIX     14-27,42-55
GPU7    SOC     SOC     SOC     SOC     PHB     PHB     PIX      X      14-27,42-55

Legend:

    X   = Self
    SOC  = Connection traversing PCIe as well as the SMP link between CPU sockets(e.g. QPI)
    PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
    PXB  = Connection traversing multiple PCIe switches (without traversing the PCIe Host Bridge)
    PIX  = Connection traversing a single PCIe switch
    NV#  = Connection traversing a bonded set of # NVLinks

P4设备物理拓扑:

        GPU0    GPU1    CPU Affinity
GPU0     X      PHB     0-11,24-35
GPU1    PHB      X      0-11,24-35

Legend:

    X   = Self
    SOC  = Connection traversing PCIe as well as the SMP link between CPU sockets(e.g. QPI)
    PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
    PXB  = Connection traversing multiple PCIe switches (without traversing the PCIe Host Bridge)
    PIX  = Connection traversing a single PCIe switch
    NV#  = Connection traversing a bonded set of # NVLinks

当在上述两者物理拓扑上进行图像压缩时,得到如下数据拷贝延迟数据ms(传递36MB的数据:分辨率单通道huffman解码后字宽采样因子,4032x3024x2x(1+0.25+0.25)):

设备类型

单卡线程数目

使用GPU卡数

时延

M40

1

1

3.023

M40

1

8

6.019

P4

1

1

2.955

P4

1

2

3.261

从上述实测延时上,也反映了M40这样的物理拓扑存在的带宽竞争问题。

数据计算阶段性能

不同型号的GPU其计算能力间存在一定的差异,性能指标上也有所不同。以下是nvidia给出的各卡之间浮点运算能力,显存大小,显存带宽,与CPU的连接方式,ECC,以及功耗做了对比。

而图像编解码压缩过程中对浮点运算性能要求不高,速度快慢与GPU的core数量有较大关系。在缩放阶段需要目标像素宽x高的gpu线程来处理目标像素的生成。

各卡的GPU core数目:

GPU

K80

M40

M4

P4

P40

cores

4992

3072

1024

2560

3840

相对于机器学习的计算量,图像处理计算量就显得很少。上述GPU物理核心数量虽然各不相同相较于少量计算而言,虽然处理耗时上存在差异,但就图像压缩处理场景而言,并不构成主要矛盾。

以下是在M40和P4上实测得计算过程消耗时延ms:

GPU

单卡线程数目

使用的GPU卡数目

IDCT

resize

DCT

huffman含api延时

M40

1

1

2.987

1.269

1.923

1.514

M40

1

8

2.985

1.257

1.922

26.72

P4

1

1

1.599

1.596

1.038

1.919

P4

1

2

1.598

1.577

1.037

1.93

由上述实测时延与GPU使用率分析,图像处理再GPU上的消耗相对较少不构成图像压缩处理的主要矛盾,那么对GPU的core 数目与浮点能力的要求就低很多。

测试过程中同样发现当单卡上的线程数目增加时,在kernel上运行的核函数增长会导致GPU上的kernel launch时间变长, 同时随着运行的卡的数目的增加,显存上内存分配释放的runtime api时延会呈现数量级的增长。经过与nvidia的同学交流,该问题主要与运行的卡数量和卡自身显存的大小有关系。

P4单卡单线程处理过程

单卡单线程,数据拷贝没有竞争,核函数执行阶段没有延迟,数据准备好之后就开始进行计算。

P4双卡每卡四线程处理过程

每卡四线程处理流之间对pcie形成竞争,launch核函数上也存在一定的延迟。

M40八卡每卡单线程处理过程

单机上运行的GPU卡越多,内存分配释放的runtime api层面的调用延时就增长的越迅速,成数量级增加远远的超过了正常计算时延。

整体影响因素和性能结论

通过上述分析,针对图片压缩处理这样计算量相对较小,数据拷贝频繁的应用场景,尽可能的减少pcie bus上的传输带宽的竞争。适当控制每卡上运行的处理流,单机配置少量的GPU卡, 尽可能的将动态分配的内存静态化,这样有利于在GPU利用率和处理时延上取得平衡。因为数据传输延迟远远大于实际计算延迟,所以我们倾向于将pcie bus的带宽跑满作为最大的处理量。 其次GPU的物理设备不需要最好的,普通的Tesla 系列GPU的计算性能已经能满足该场景下的计算加速,在物理拓扑上最好采用GPU直连CPU的模式与物理CPU均匀分配连接。

利用当前的M40架构,在GPU加速所取得的现网时延ms(编解码部分没放到GPU上进行)

分辨率

GPU

CPU

docker

>2000x2000

143

366

393

2000x2000~1500x1500

55

145

175

1500x1500~1000x1000

37

98

114

1000x1000~500x500

28

57

74

500x500~200x200

16

24

47

200x200~100x100

8

10

13

当图像分辨率超过500x500之后,使用GPU进行图像压缩相对于纯CPU时延降低了50%以上。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏量子位

零基础可上手 | 手把手教你用Cloud AutoML做毒蜘蛛分类器

近日,一名叫Matt Fraser的小哥用Cloud AutoML制作了一个分类器,能识别分类澳大利亚的各种毒蜘蛛。

1036
来自专栏PPV课数据科学社区

把吴恩达深度学习系列课程画出来,这有份诚意满满的笔记求查收

在吴恩达机器学习系列课程完结后不久,一位名叫Tess Ferrandez的小姐姐在推特上分享了一套自己的课程笔记,瞬间收获了3k+赞和1k+转发。 不同于满屏公...

3065
来自专栏python小白到大牛

Python识别验证码的另一种花样玩法

这里使用了 pytesseract 来进行验证码识别,它是基于 Google 的 Tesseract-OCR ,所以在使用之前需要先安装 Tesseract-O...

1125
来自专栏宏伦工作室

豆瓣电影数据分析和可视化

2167
来自专栏数据派THU

一招检验10大深度学习框架哪家强!

来源:机器之心 本文长度为2698字,建议阅读4分钟 本文通过构建同一个神经网络,对比当前最流行的 10 种深度学习框架。 [ 导读 ]近日,Ilia Karm...

1607
来自专栏企鹅号快讯

WEKA的使用指南

“借着年终总结,回顾个好用的数据挖掘工具。” WEKA是一个貌似比较小众的数据挖掘工具,在应用的普遍性上远远不如R、Python等软件。我在机缘巧合之下,从一门...

2266
来自专栏图形学与OpenGL

计算机图形学课程设计内容及要求

目标:以图形学算法为目标,深入研究。继而策划、设计并实现一个能够表现计算机图形学算法原理的或完整过程的演示系统,并能从某些方面作出评价和改进意见。通过完成一个完...

786
来自专栏机器人网

工业控制PID系统的十五个基本概念

PID调节系统PID功能由PID调节器或DCS系统内部功能程序模块实现,了解与PID调节相关的一些基本概念,有助于PID入门新手快速熟悉调节器应用,在自动调节系...

2686
来自专栏机器之心

从Caffe2到TensorFlow,十种框架构建相同神经网络效率对比

3234
来自专栏数据科学与人工智能

【Python环境】python的nltk中文使用和学习资料汇总帮你入门提高

nltk是一个python工具包, 用来处理和自然语言处理相关的东西. 包括分词(tokenize), 词性标注(POS), 文本分类, 等等现成的工具. 1....

3536

扫码关注云+社区