手把手教你如何用Julia做GPU编程(附代码)东京1.5分彩预测

编辑:凯恩/2018-12-01 13:11

  本文旨在快速介绍GPU的工作原理,详细介绍当前的Julia GPU生态系统,并让读者了解简单的GPU编程是多么的容易。

  GPU是一个大规模并行处理器,具有几千个并行处理单元。 例如,本文中使用的Tesla k80提供4992个并行CUDA内核。 GPU在频率,延迟和硬件功能方面与CPU完全不同,但有点类似于拥有4992个内核的慢速CPU!

  可启用并行线程的数量可以大幅提高GPU速度,但也让它的使用性变得更加困难。让我们来详细看看在使用这种原始动力时,你会遇到哪些缺点:

  GPU是一个独立的硬件,具有自己的内存空间和不同的架构。 因此,从RAM到GPU存储器(VRAM)的传输时间很长。 即使在GPU上启动内核(换句话说,调度函数调用)也会带来较大的延迟。 GPU的时间约为10us,而CPU的时间则为几纳秒。

  GPU函数(内核)本质上是并行的,所以编写GPU内核至少和编写并行CPU代码一样困难,但是硬件上的差异增加了相当多的复杂性

  CUDA和OpenCL之间存在分歧,OpenCL是用于编写低级GPU代码的主要框架。虽然CUDA只支持英伟达硬件,但OpenCL支持所有硬件,但有些粗糙。

  Julia的诞生是个好消息!它是一种高级脚本语言,允许你在Julia本身编写内核和周围的代码,同时在大多数GPU硬件上运行!

  大多数高度并行的算法需要通过相当多的数据来克服所有线程和延迟开销。因此,大多数算法都需要数组来管理所有数据,这需要一个好的GPU数组库(array library)作为关键基础。

  GPUArrays.jl是Julia的基础。它提供了一个抽象数组实现,专门用于使用高度并行硬件的原始功能。它包含设置GPU所需的所有功能,启动Julia GPU函数并提供一些基本的数组算法。

  抽象意味着它需要以CuArrays和CLArrays形式的具体实现。由于继承了GPUArrays的所有功能,东京1.5分彩预测,它们都提供完全相同的接口。唯一的区别出现在分配数组时,这会强制你决定数组是否位于CUDA或OpenCL设备上。关于这一点的更多信息,请参阅内存部分。

  GPUArrays有助于减少代码重复,因为它允许编写独立于硬件的GPU内核,可以通过CuArrays或CLArrays将其编译为本机GPU代码。因此,许多通用内核可以在继承自GPUArrays的所有packages之间共享。

  一点选择建议:CuArrays仅适用于Nvidia GPU,而CLArrays适用于大多数可用的GPU。CuArrays比CLArrays更稳定,并且已经可以在Julia 0.7上运行。速度上差异不明显。我建议两者都试一下,看看哪个效果最好。

  让我们用一个简单的交互式代码示例来快速说明为什么要将计算转移到GPU上,这个示例计算julia set:

  如你所见,对于大型数组,通过将计算移动到GPU可以获得稳定的60-80倍的加速。而且非常简单,只需将Julia array转换为GPUArray。

  有人可能认为GPU的性能受到像Julia这样的动态语言的影响,但Julia的GPU性能应该与CUDA或OpenCL的原始性能相当。Tim Besard在集成LLVM Nvidia编译pipeline方面做得非常出色,达到了与纯CUDA C代码相同(有时甚至更好)的性能。Tim发表了一篇非常详细的博文,里面进一步解释了这一点[1]。CLArrays方法有点不同,它直接从Julia生成OpenCL C代码,具有与OpenCL C相同的性能!

  为了更好地了解性能并查看与多线程CPU代码的比较,我收集了一些基准测试[2]。

  GPU具有自己的存储空间,包括视频存储器(VRAM),不同的高速缓存和寄存器。无论你做什么,任何Julia对象都必须先转移到GPU才能使用。并非Julia中的所有类型都可以在GPU上工作。

  所有这些Julia类型在转移到GPU或在GPU上创建时表现都不同。下表概述了预期结果:

  创建位置描述了对象是否在CPU上创建然后传输到GPU内核,或者是否在内核的GPU上创建。这个表显示了是否可以创建类型的实例,并且对于从CPU到GPU的传输,该表还指示对象是否通过引用复制或传递。

  使用GPU时的一个很大的区别是GPU上没有垃圾回收( garbage collector, GC)。这不是什么大问题,因为为GPU编写的高性能内核不应该一开始就创建任何GC-tracked memory。

  为GPU实现GC是可能的,但请记住,每个执行的内核都是大规模并行的。在~1000 GPU线程中的每一个线程创建和跟踪大量堆内存将很快破坏性能增益,因此这实际上是不值得的。

  作为内核中堆分配数组的替代方法,你可以使用GPUArrays。GPUArray构造函数将创建GPU缓冲区并将数据传输到VRAM。如果调用Array(gpu_array),数组将被转移回RAM,表示为普通的Julia数组。这些GPU数组的Julia句柄由Julia的GC跟踪,如果它不再使用,GPU内存将被释放。

  因此,只能在设备上使用堆栈分配,并且对其余的预先分配的GPU缓冲区使用。由于传输非常昂贵的,因此在编程GPU时尽可能多地重用和预分配是很常见的。

  许多操作是已经定义好的。最重要的是,GPUArrays支持Julia的fusing dot broadcasting notation。这种标记法允许你将函数应用于数组的每个元素,并使用f的返回值创建一个新数组。这个功能通常称为映射(map)。 broadcast 指的是具有不同形状的数组被散布到相同的形状。

  这意味着在不分配堆内存(仅创建isbits类型)的情况下运行的任何Julia函数都可以应用于GPUArray的每个元素,并且多个dot调用将融合到一个内核调用中。由于内核调用延迟很高,这种融合是一个非常重要的优化。

  如下面的视频所示,这个GPU加速烟雾模拟是使用GPUArrays + CLArrays创建的,可在GPU或CPU上运行,GPU版本的速度提高了15倍:

  只需将数组转换为GPUArrays(使用gpu(array)),我们就可以将整个计算转移到GPU并获得相当不错的速度提升。这要归功于Julia复杂的AbstractArray基础架构,GPUArray可以无缝地集成到其中。接着,加拿大99预测,如果你省略了对转换为GPUArray,代码也将使用普通的Julia数组运行——但当然这是在CPU上运行。你可以通过将use_gpu = true更改为use_gpu = false并重试初始化和训练单元格来尝试这个操作。对比GPU和CPU,CPU运行时间为975秒,GPU运行时间为29秒 ——加速了约33倍!

  另一个值得关注的好处是,GPUArrays不需显式地实现自动微分以有效地支持神经网络的反向传播。这是因为Julia的自动微分库适用于任意函数,并发出可在GPU上高效运行的代码。这有助于帮助Flux以最少的开发人员在GPU上工作,并使Flux GPU能够有效地支持用户定义的函数。在没有GPUArrays + Flux之间协调的情况下开箱即用是Julia的一个非常独特的特性,详细解释见[3].

  只需使用GPUArrays的通用抽象数组接口,而不用编写任何GPU内核,就可以做很多事了。但是,在某些时候,可能需要实现一个需要在GPU上运行的算法,并且不能用通用数组算法的组合来表示。

  好的一点是,GPUArrays通过一种分层方法减少了大量的工作,这种方法允许你从高级代码开始编写低级内核,类似于大多数OpenCL / CUDA示例里的。它还允许你在OpenCL或CUDA设备上执行内核,从而抽象出这些框架中的任何差异。

  使这成为可能的函数名为gpu_call。它可以被称为 gpu_call(kernel, A::GPUArray, args),并将在GPU上使用参数 (state, args...) 调用内核。State是一个后端特定对象,用于实现获取线程索引之类的功能。GPUArray需要作为第二个参数传递,一遍分派到正确的后端并提供启动参数的缺省值。

  简单来说,上面的代码将在GPU上并行调用julia函数内核length(A) 次。内核的每个并行调用都有一个线程索引,我们可以使用它来安全地索引到数组A和B。如果我们计算自己的索引,而不是使用linear_index,我们需要确保没有多个线程读写同一个数组位置。因此,如果我们使用线程在纯Julia中编写,其对应版本如下:

  因为这个函数没有做很多工作,我们看不到完美的扩展,但线程和GPU版本仍然提供了很大的加速。

  GPU比线程示例展示的要复杂得多,因为硬件线程是在线程块中布局的——gpu_call在简单版本中抽象出来,但它也可以用于更复杂的启动配置:

  在上面的示例中,你可以看到更复杂的启动配置的迭代顺序。确定正确的迭代+启动配置对于达到GPU的最佳性能至关重要。

  在将可组合的高级编程引入高性能世界方面,Julia取得了长足的进步。现在是时候对GPU做同样的事情了。

  希望Julia降低开始在GPU上编程的标准,并且我们可以为开源GPU计算发展可扩展的平台。第一个成功案例是通过Julia packages实现自动微分,这些软件包甚至不是为GPU编写,因此这给了我们很多理由相信Julia在GPU计算领域的可扩展和通用设计是成功的。