AMD OpenCL大学课程(11)

简介: 性能优化 1、线程映射    所谓线程映射是指某个线程访问哪一部分数据,其实就是线程id和访问数据之间的对应关系。 合适的线程映射可以充分利用硬件特性,从而提高程序的性能,反之,则会降低性能。    请参考Static Memory Access Pattern Analysis on a Massively Parallel GPU这篇paper,文中讲述线程如何在算法中充分利用线程映射。

性能优化

1、线程映射

   所谓线程映射是指某个线程访问哪一部分数据,其实就是线程id和访问数据之间的对应关系

合适的线程映射可以充分利用硬件特性,从而提高程序的性能,反之,则会降低性能。

   请参考Static Memory Access Pattern Analysis on a Massively Parallel GPU这篇paper,文中讲述线程如何在算法中充分利用线程映射。这是我在google中搜索到的下载地址:http://www.ece.neu.edu/~bjang/patternAnalysis.pdf

   使用不同的线程映射,同一个线程可能访问不同位置的数据。下面是几个线程映射的例子:

image

image

      我们考虑一个简单的串行矩阵乘法:这个算法比较适合输出数据降维操作,通过创建N*M个线程,我们移去两层外循环,这样每个线程执行P个加法乘法操作。现在需要我们考虑的问题是,线程索引空间究竟应该是M*N还是N*M?

image

    当我们使用M*N线程索引空间时候,Kernel如下图所示:

image

   而使用N*M线程索引空间时候,Kernel如下图所示:image

    使用两种映射关系,程序执行结果是一样的。下面是在nv的卡GeForce 285 and 8800 GPUs上的执行结果。可以看到映射2(及N*M线程索引空间),程序的performance更高。

image

    性能差异主要是因为在两种映射方式下,对global memory访问的方式有所不同。在行主序的buffer中,数据都是按行逐个存储,为了保证合并访问,我们应该把一个wave中连续的线程映射到矩阵的列(第二维),这样在A*B=C的情况下,会把矩阵B和C的内存读写实现合并访问,而两种映射方式对A没有影响(A由i3决定顺序)。

   完整的源代码请从:http://code.google.com/p/imagefilter-opencl/downloads/detail?name=amduniCourseCode4.zip&can=2&q=#makechanges下载,程序中我实现了两种方式的比较。结果确实第二种方式要快一些。

   下面我们再看一个矩阵转置的例子,在例子中,通过改变映射方式,提高了global memory访问的效率。

image

   矩阵转置的公式是:Out(x,y) = In(y,x)

   从上图可以看出,无论采取那种映射方式,总有一个buffer是非合并访问方式(注:在矩阵转置时,必须要把输入矩阵的某个元素拷贝到临时位置,比如寄存器,然后才能拷贝到输出矩阵)。我们可以改变线程映射方式,用local memory作为中间元素,从而实现输入,输出矩阵都是global memory合并访问。

image

  下面是AMD 5870显卡上,两种线程映射方式实现的矩阵转置性能比较:

image

    完整代码:http://code.google.com/p/imagefilter-opencl/downloads/detail?name=amduniCourseCode5.zip&can=2&q=#makechanges

2、Occupancy

    前面的教程中,我们提到过Occupancy的概念,它主要用来描述CU中资源的利用率。

    OpenCL中workgroup被映射到硬件的CU中执行,在一个workgroup中的所有线程执行完之后,这个workgroup才算执行结束。对一个特定的cu来说,它的资源(比如寄存器数量,local memory大小,最大线程数量等)是固定的,这些资源都会限制cu中同时处于调度状态的workgroup数量。如果cu中的资源数量足够的的话,映射到同一个cu的多个workgroup能同时处于调度状态,其中一个workgroup的wave处于执行状态,当处于执行状态的workgroup所有wave因为等待资源而切换到等待状态的话,不同workgroup能够从就绪状态切换到ALU执行,这样隐藏memory访问时延。这有点类似操作系统中进程之间的调度状态。我简单画个图,以供参考:

image

  • 对于一个比较长的kernel,寄存器是主要的资源瓶颈。假设kernel需要的最大寄存器数目为35,则workgroup中的所有线程都会使用35个寄存器,而一个CU(假设为5870)的最大寄存器数目为16384,则cu中最多可有16384/35=468线程,此时,一个workgroup中的线程数目(workitem)不可能超过468,
  • 考虑另一个问题,一个cu共16384个寄存器,而workgroup固定为256个线程,则使用的寄存器数量可达到64个。

    每个CU的local memory也是有限的,对于AMD HD 5XXX显卡,local memory是32K,NV的显卡local memory是32-48K(具体看型号)。和使用寄存器的情况相似,如果kernel使用过多的local memory,则workgroup中的线程数目也会有限制。

   GPU硬件还有一个CU内的最大线程数目限制:AMD显卡256,nv显卡512。

   NV的显卡对于每个CU内的激活线程有数量限制,每个cu 8个或16个warp,768或者1024个线程。

   AMD显卡对每个CU内的wave数量有限制,对于5870,最多496个wave。

   这些限制都是因为有限的资源竞争引起的,在nv cuda中,可以通过可视化的方式查看资源的限制情况。

3、向量化

   向量化允许一个线程同时执行多个操作。我们可以在kernel代码中,使用向量数据类型,比如float4来获得加速。向量化在AMD的GPU上效果更为明显,这是因为AMD的显卡的stream core是(x,y,z,w)这样的向量运算单元。

>   下图是在简单的向量赋值运算中,使用float和float4的性能比较。

image

    kernel代码为:

image

    完整代码请从:http://code.google.com/p/imagefilter-opencl/downloads/detail?name=amduniCourseCode6.zip&can=2&q=#makechanges下载

相关实践学习
在云上部署ChatGLM2-6B大模型(GPU版)
ChatGLM2-6B是由智谱AI及清华KEG实验室于2023年6月发布的中英双语对话开源大模型。通过本实验,可以学习如何配置AIGC开发环境,如何部署ChatGLM2-6B大模型。
相关文章
|
6月前
|
机器学习/深度学习 人工智能 负载均衡
MoE架构:大模型的规模扩展革命
MoE(混合专家)架构通过稀疏激活多个专业化子网络,实现高效计算与大规模模型的结合,提升训练推理效率及模型可扩展性,成为大模型发展的重要范式。
|
10月前
|
存储 人工智能 调度
上海创智学院联合无问芯穹发布Megrez2.0,本征架构突破端模型不可能三角,以终端算力撬动云端智能
终端是实现数字智能和生命智能自由交互的重要接口,持续帮助人类拓展生产能力的边界。当下,终端智能面临着“能效-空间-智能”的不可能三角:以DeepSeek-R1为例,其参数规模高达6710亿,超出了大部分笔记本电脑的内存容量;即使勉强在一台笔记本电脑上成功运行满血版模型,理论上坚持不到9分钟就会耗尽电池;如果通过蒸馏,将满血版模型压缩到更小尺寸,此时的精度损失又可能满足不了智能水平的要求。
248 0
上海创智学院联合无问芯穹发布Megrez2.0,本征架构突破端模型不可能三角,以终端算力撬动云端智能
|
机器学习/深度学习 存储 人工智能
【AI系统】低比特量化原理
模型量化是将浮点数模型参数转化为低比特整数表示的技术,旨在减少模型大小、内存消耗及推理延迟,但会带来精度损失。本文介绍量化的基本原理、优势及挑战,涵盖量化训练、动态与静态离线量化等方法,并探讨线性与非线性量化、饱和与非饱和量化等技术细节。
937 2
【AI系统】低比特量化原理
|
Python C++ 前端开发
PyTorch 2.2 中文官方教程(十一)(1)
PyTorch 2.2 中文官方教程(十一)
523 1
PyTorch 2.2 中文官方教程(十一)(1)
|
存储 机器学习/深度学习 计算机视觉
字节开源大模型量化新思路,2-bit量化模型精度齐平fp16
【5月更文挑战第25天】字节跳动研究团队提出新型量化方法decoupleQ,实现2-bit量化模型与fp16/bf16同等精度。该方法通过参数分解,将量化转化为数学优化问题,简化处理并提高硬件兼容性。decoupleQ在大型语音模型上验证了其2-bit量化效果,降低了存储和计算成本,适用于资源受限环境。论文开源,为量化技术发展带来新视角。
766 4
|
测试技术
JavaWeb - Hutool Bug HttpResponse body 方法中文乱码
JavaWeb - Hutool Bug HttpResponse body 方法中文乱码
998 0
|
存储 算法 异构计算
GGML 非官方中文文档(5)
GGML 非官方中文文档
528 1
|
存储 缓存 C++
GGML 非官方中文文档(1)
GGML 非官方中文文档
782 1
|
存储 算法 图计算
GGML 非官方中文文档(4)
GGML 非官方中文文档
746 0
|
存储 异构计算 索引
GGML 非官方中文文档(3)
GGML 非官方中文文档
584 0

热门文章

最新文章