精华内容
下载资源
问答
  • 并行编程模型

    千次阅读 2017-03-12 17:19:33
    在计算领域,并行编程模型是并行计算机体系架构的一种抽象,它便于编程人员在程序中编写算法及其组合。一个编程模型的价值可以通过其通用性(generality)来判断,如不同体系架构的一系列不同的问题能否在该模型中很...

       在计算领域,并行编程模型是并行计算机体系架构的一种抽象,它便于编程人员在程序中编写算法及其组合。一个编程模型的价值可以通过其通用性(generality)来判断,如不同体系架构的一系列不同的问题能否在该模型中很好地表示以及其性能如何,编译后的程序执行效率有多高等。并行编程模型的实现有两种方式,作为已有的语言的一种扩展,通过库的形式来调用,或者作为一种全新的语言。

         围绕一个实际的编程模型的共识是重要的,因为它会导致构建出支持该模型的不同的并行计算机,从而提高软件的兼容性。在这种意义上说,编程模型是硬件和软件之间的桥梁。

    并行编程模型可以分为两类:(1)进程通信(process interaction)和问题分解(problem decomposition)。下面我们简要介绍这两类模型有哪些形式。

          进程通信:进程通信涉及并行进程互相通信的机制。最常用的通信形式是共享内存shared memory)和消息传递(message passing),但是通信形式也可以是隐式的,对程序员是不可见的。

            1)共享内存:共享内存是进程间传递数据的一种高效方法。在共享内存模型中,并行进程共享一个进行异步读取的全局地址空间。异步并发访问可能导致条件竞争,因此需要同步机制来避免条件竞争,这些机制包括锁,信号量,管程(monitor)。传统的多核处理器是直接支持共享内存的,所以导致很多利用该特性的语言和库出现,如CilkOpenMPThreading Building Blocks

    2)消息传递:在消息传递模型中,并行进程是通过消息传递来交换数据的。这些通信可以是异步的,即消息可以在接收者做好准备前发送,也可以是同步的,即只有接受者准备好接收消息时才能发送。消息传递的CSPCommunicating sequential processes)模型使用同步通信channel来连接进程,这种模式被OccamLimboGo等语言所采用的。相反,Actor模型则使用异步消息传递。这种模式被DScalaSALSA等语言所采用。

    3)隐式通信(Implicit interaction):在隐式通信中,进程通信对程序员来说是不可见的,进程通信是由编译器或者运行时来处理和实现。并发被预置在高级操作子中的领域特定语言(domain-specific language)和函数式编程语言是隐式并行的典型例子,因为无副作用(side-effect)允许非依赖的函数可以并发执行。但是这种并行模式是很难管理的。函数式语言如Concurrent HaskellConcurrent ML提供了显示管理并行化的功能。

    问题分解:并行程序是由同时运行的进程组成。问题分解涉及所有进程如何被组织起来的方式。问题分解包括三种并行模型:(1)任务并行模型(task parallelism);(2)数据并行模型(Data parallelism);(3)隐式并行模型(Implicit parallelism)。

    1)任务并行化:任务并行模型关注进程或线程的执行。这些进程在行为上是不同的,而且相互之间的通信是非常重要的。任务并行化是表示消息传递通信的一种自然方式。Flynn分类法中,任务并行化的三种形式是MIMDMPMD或者MISD

    2)数据并行化:数据并行化关注在数据集上执行的操作。一组任务对数据集进行运算,但是会对不同的分区进行运算。在Flynn分类法中,任务并行化的三种形式是SIMDSPMD或者SIMD

    3) 隐式并行化:对程序员来说是不可见的,由编译器、运行时或硬件负责实现。例如,在编译器领域,自动并行化就是将顺序执行的代码转换为并行代码的过程;在计算机体系架构领域,超标量执行就是一种利用指令级并行来实现并行运算的机制。

     

      并行编程模型与并行计算模型是密切相关的。并行计算模型是用于分析计算进程代价的一种抽象,它不是必须具备可行性,即可以在硬件或软件上可以被高效地实现。相反,并行编程模型则明确地暗示了软硬件实现的可行性考虑。一种并行编程语言的实现可以基于一个或多个并行编程模型。例如,高性能Fortran就是基于共享内存通信和数据并行问题分解来实现的,Go语言则同时提供了共享内存和消息传递两种通信机制。

     

    并行编程模型的例子

    名字

    进程通信类别

    问题分解类别

    样例实现

    Actor model

    Asynchronous

    message passing

    Task

    D, Erlang, Scala, SALSA

    Bulk synchronous

    parallel

    Shared memory

    Task

    Apache Giraph, Apache Hama, BSPlib

    Communicating

    sequential processes

    Synchronous

    message passing

    Task

    Ada, Occam, VerilogCSP, Go

    Circuits

    Message passing

    Task

    Verilog, VHDL

    Dataflow

    Message passing

    Task

    Lustre, TensorFlow, Apache Flink

    Functional

    Implicit

    Task

    Concurrent Haskell, Concurrent

    ML

    LogP machine

    Synchronous

    message passing

    Not specified

    None

    Parallel random

    access machine

    Shared memory

    Data

    CilkCUDAOpenMPThreading Building BlocksXMTC


    展开全文
  • 任务并行编程模型是近年来多核平台上广泛研究和使用的并行编程模型,旨在简化并行编程和提高多核利用率.首先,介绍了任务并行编程模型的基本编程接口和支持机制;然后,从3 个角度,即并行性表达、数据管理和任务调度介绍...
  • 任务并行编程模型

    2020-02-03 19:17:04
    并行编程模型是底层体系结构与上层应用程序之间的桥梁,向上隐藏并行处理器的细节,提供给程序员并行表达的方法;向下充分利用硬件资源、高效且正确地完成应用需求.任务划分、任务映射、数据分布、通信和同步是设计并行...

    并行编程模型是底层体系结构与上层应用程序之间的桥梁,向上隐藏并行处理器的细节,提供给程序员并行表达的方法;向下充分利用硬件资源、高效且正确地完成应用需求.任务划分、任务映射、数据分布、通信和同步是设计并行编程模型时需要考虑的 5 个关键要素.任务并行编程模型主要关注共享存储的平台,数据分为共享和私有两种存储属性,通过共享数据进行通信.因此,该编程模型的研究重点是任务划分、任务映射和同步这个关键要素.任务并行编程模型把任务作为并行的基本单位,提供任务划分和同步的编程接口,把任务划分和同步工作交给程序员完成,用户可以把应用程序划分出大量细粒度任务.然而,具体到每个任务到底是并行执行还是串行执行、在哪个物理核上执行以及如何实现任务之间的同步则由运行时系统完成.任务并行编程模型提倡嵌套的递归任务,并引入以任务窃取为核心的用户级线程调度,实现程序的高性能和动态的负载平衡 [1] .
    任务并行编程模型提供显式的任务划分和同步编程接口以及隐式的任务映射机制.前者关注可编程性,后者关注执行效率.任务并行编程模型支持非规则应用程序,把逻辑任务与物理线程分离,从而独立于处理器核数.但多核时代需要的是面向更广阔应用领域的、易编程、高产能的并行编程工具,该模型的编程接口(并行性表达和数据管理)和运行时支持(任务调度) [1] 面临如下挑战:
    (1) 该模型的编程接口能支持的并行模式有限,需要丰富编程接口,表达多种多样的并行性.例如,spawnsync 能够实现嵌套并行控制结构,但不能高效实现循环级并行,于是,程序员需要把数据并行的应用程序转换成嵌套并行,才能用该模型编写并行程序.另外,无条件原子块结构和有条件原子块结构是重要的并行任务结构,如何表达以及如何高效支持都需要深入研究; [1]
    (2) 该模型把数据分为共享和私有两种,通过共享数据进行通信.但有些数据是部分任务共享,或者一个线程内执行的所有任务共享,因此需要对数据进一步区分共享范围,需要研究如何高效实现不同级别的共享数据 [1] ;
    (3) 该模型的运行时系统负责把逻辑任务映射到物理线程上去执行,其核心任务是提高执行效率.存在的问题有:(a) 运行时系统是一个软件层,与应用程序链接在一起,运行在用户空间上.用软件实现任务窃取是有代价的,问题是能否进一步降低运行时系统开销;(b) 任务窃取采用最早任务优先窃取策略,该策略的“深度优先执行”能够提高 cache 的利用率.但随机选择线程进行任务窃取,而没有考虑多核处理器的存储层次和处理器架构特点,对于局部性敏感的应用会产生影响.因此,任务调度时需要根据存储部件的层次、容量、访问延迟以及数据的访问局部性、重用度和层次性等因素进行局部性敏感的调度;© 集群系统和众核处理器都远比多核处理器要复杂,拥有更大量的计算资源,如何管理和使用硬件资源,充分利用体系结构的并行性和局部性来提高性能,也需要深入加以研究 [1] .

    展开全文
  • 并行编程模型,Lustre

    2015-12-27 16:31:31
    模,要完成这些目标,需要选择合适的并行编程模型并行编程模型与并行计算机体系 结构紧密相关,目前主流的并行编程模型包括共享内存编程模型和分布式内存编程模型。 共享内存体系架构(如NUMA,SMP 等)下的...

    1      并行编程模型

    现代高性能计算机通过将单个任务并行化,降低任务处理时间、提升计算精度或扩大规

    模,要完成这些目标,需要选择合适的并行编程模型,并行编程模型与并行计算机体系

    结构紧密相关,目前主流的并行编程模型包括共享内存编程模型和分布式内存编程模型。

    共享内存体系架构(如NUMASMP 等)下的编程模型主要是共享内存编程模型,共

    享内存编程模型具有单一地址空间,编程方法简单,但可移植性和可扩展性较差的特点,

    目前使用较多的是OpenMPOpenMP 是基于线程级的并行化,它通过在串行脚本内添

    pragma 制导语句来指导并行化。

    分布式内存体系架构(如MMPCluster 等)下的编程模型是分布式内存编程模型,其

    中较常用的是消息传递编程模型,具有多地址空间,编程较复杂,可移植性和可扩展性

    较好的特点,目前使用较多的是MPIMessage Passing Interface),以函数库的形式被程

    序调用,MPI 是基于进程级的并行,自1993 2 月发布了MPI-1.0 标准后,至今已发

    展了20 年,并于2012 9 月发布了最新的MPI-3.0 标准,基于MPI 标准,业界有多种

    开源和商用的MPI 实现,如开源的有MPICHMVAPICHOpenMPI 等,商用的有Intel

    MPIPlatform MPI 等等。

    当前高性能集群具有多层次结构,集群系统兼具了共享内存体系结构和分布式内存体系

    结构的特点,这就导致了共享内存编程模型和分布式内存编程模型相结合的混合编程模

    型出现,在节点内部使用共享内存编程模型,而节点间则采用分布式内存编程模型,即

    OpenMP+MPI 的模式,其优势在于结合了OpenMP 线程级的细粒度并行(如循环并行)

    MPI进程级的粗粒度并行(如区域分解),在很多情况下,其性能要优于单纯的OpenMP

    程序或MPI 程序。

    计算机通过文件系统管理、存储数据,而信息爆炸时代中人们可以获取的数据成指数倍

    的增长,单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式,在容量大小、

    容量增长速度、数据备份、数据安全等方面的表现都差强人意。

    分布式文件系统(Distributed File System)可以有效解决数据的存储和管理难题:将固

    定于某个地点的某个文件系统,扩展到任意多个地点/多个文件系统,众多的节点组成一

    个文件系统网络。每个节点可以分布在不同的地点,通过网络进行节点间的通信和数据

    传输。人们在使用分布式文件系统时,无需关心数据是存储在哪个节点上、或者是从哪

    个节点从获取的,只需要像使用本地文件系统一样管理和存储文件系统中的数据。分布

    式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问

    的服务器。

    当前比较流行的分布式文件系统包括:LustreHadoopMogileFSFreeNASFastDFS

    NFSOpenAFSMooseFSpNFS、以及GoogleFS

    1.1      Lustre

    Lustre 体系结构是一个为集群设计的存储体系结构。其核心组件是运行在Linux 操作系

    统上、支持标准的POSIX* UNIX 文件系统接口、并遵循GPL2.0 许可的Lustre 文件系

    统。据IDC 的统计,Lustre 是在HPC 领域应用最广的文件系统,世界上最快的50 个超

    算网站有60%都使用Lustre

    注:由于Lustre 结构的特点,每两台设备间存在备份关系,所以有时称为集群文件系统,而对于I/O

    的处理模式来说,Lustre 业务是并行处理的所以也可称作并行文件系统,而对于业务的处理来说,

    Lustre I/O 通常会分发给不同的I/O 节点处理,所以也可称之为分布式文件系统,以上三种称

    谓只是分类角度不同,没有对错之分。

    在集群计算机里,计算机与磁盘间数据交换的提升无法跟上微处理器和内存增长的速度,

    从而也拖累了应用程序的性能。Lustre 文件系统很好的解决了这一问题,它可为数以万

    计的客户端系统服务,提供PB 级的存储容量和百吉比特字节每秒(GB/秒)的I/O

    吐量。

    Lustre 文件系统基于C/S 模式设计,其对象存储的特性(客户端与磁盘上的文件分离,

    存储的升级和变更不影响客户端的使用),极大的降低了企业购买存储设备的成本,并

    改变企业购买存储的方式。分布式和并行化的工作方式,使Lustre 的用户不必一次性购

    买价格高昂的高端存储来满足性能需求,而可以通过低端存储和I/O 节点的动态扩充来

    满足业务需求的增长。同时客户为每个集群应用建立一个文件系统,也可转换为使用全

    局统一命名的文件系统,客户可以为每个文件配置条带等文件系统属性,从而减少了集

    群间的数据拷贝、简化的集群的管理,聚集了服务器和集群的存储容量,减少了资源的

    浪费,更易于性能动态的扩展。

    Lustre 文件系统支持多种高性能、低时延的网络,例如基于OFEDOpenFabrics Enterprise

    Distribution)的InfiniBand。在多种不同的RDMA 网络间还可以通过Lustre routing 进行

    桥接。保证了Lustre 可以获得充足的网络带宽。

    Lustre 文件系统通过共享存储分区的方式支持OSTObject storage target)的AA

    Active-Active)故障切换,实现了底层故障对应用透明,MMPMultiple mount protection

    技术的使用为可能导致文件系统故障的系统错误提供了完整的保护。

    组件

    Lustre 文件系统的主要组件有:MDSMDTOSSOSTClient。各个组件间的链接

    关系如图2-7 所示。

    MDSMetadata Server):MDS 负责管理Lustre 文件系统的文件名、目录、权限、文件

    结构等元数据信息,MDS 生成的元数据存储在一个或者多个MDT 上,并为每个Client

    提供服务。MDS 可以有多个,但只有一个为主MDS,其余MDS 工作在备份模式。

    MDTMetadata Target):每个文件系统都有一个MDTMDT 可以是MDS 本地硬盘(只

    有一个MDS 时)、也可以是远端存储的一个LUN 设备。一个MDT 可以通过同时映射

    于华为OceanStor V3 融合存储部署HPC 分布式文件系统参考架构

    载最佳实践

    给两台主机,供多个MDS 进行访问,但同一时刻只能有一个MDS 进行访问,通过这

    种方式可以实现MDS 的高可用性。

    OSSObject Storage Servers):OSS Client 提供文件I/O 服务,客户端从MDS 获取元

    数据信息后,从OSS 访问文件数据,文件数据最终存储在与OSS 相连的OST 上。通常

    每个OSS 会配置2~8 OST,每个OST 最大16TB

    OSTObject Storage Target):用户文件存储在一个或者多个对象中,每个对象对应一个

    独立的OST,每个文件可以存储在一个OST 上,也可以跨越多个OST 进行存储。一个

    OST 可以通过同时映射给两台主机实现OSS 的高可用性。

    Lustre ClientLustre 客户端是指装有Lustre 客户端软件并可以挂载Lustre 文件系统的计

    算节点、虚拟化节点或者桌面节点。在高性能集群中,通常是计算节点、管理节点或登

    陆节点。

    2-7 Lustre 组件组网示意图

    文件存储

    Lustre 文件系统使用FIDLustre file identifiers)作为文件或者对象的标识。而文件数据

    OST 中存储位置的信息被存储在MDT 上,形式为FID 的一个扩展属性,称之为layout

    EAextended attribute)。

    假设文件是一个数据文件(非目录和链接符),MDT 上存储着这个文件在OST 上的存

    放位置。如果MDT 指向的是单个OST 对象,则整个数据文件都存储在这个OST 对象

    上,如果MDT 文件指向多个对象,文件则被使用RAID0 的方式条带化到各个对象。如

    下图所示,当一个客户端需要读写数据文件时,它首先需要从MDT 处获取layout EA

    的信息,由layout EA 信息可以得知具体的数据被存放在哪些OST 上,然后即可是读写。

    2-8 Layout EA 存储示意图

    Lustre 文件系统高性能的一个主要因素是它可以在多个OST 间通过round-robin 算法进

    行基于数据的分段或者chunk 的条带化,用户可以为每个文件配置条带数目、大小、应

    用于哪个OST。当访问单一文件时,条带化可以使文件系统的性能大于单个OST 的带

    宽。条带化还用于单个OST 没有足够的空间存放整个文件时,使用多个OST 同时存储

    数据。

    举例说明文件在Lustre 中的存储方式,文件C stripe_size 比文件A stripe_size 大,

    文件C 允许更多的数据存放在单个分条。文件A stripe_count 3,即数据跨越三个

    对象存储,文件B 和文件C stripe_count 1。在第一次下发I/O 时,文件A stripe_size

    被存放在了OST1OSTOST3 上。第二次下发I/O 时,文件A、文件B、文件C、同

    时写入,根据均衡算法,最终文件A 存储了两份到OST1 上,文件B 存储在了OST2 上,

    文件C 存储在了OST3 上,而整体来看,OST1OST2OST3 存储的数据是一样多的。

    2-9 Lustre 文件存储示意图

    由上面的例子也可以看出来,Lustre 文件系统中的文件大小不受限于单个OST 的大小,

    文件可以被条带化,跨越多个对象(最多200 个)来进行存储,使用ldiskfs 时每个对象

    最大可以到16TB,总文件大小最大可以达31.25PB,使用zfs 时可以最大到256PB,总

    文件大小最大可以达8EB

    文件读写

    Lustre 文件系统中,一个文件读写主要经历以下流程:

    l Lustre 客户端向MDT 发送file open 的请求;

    l MDT 收到请求后查找存储这个文件的对象的layout EA 信息;

    l MDT layout EA 信息通过FID 返回给Lustre 客户端;

    l 客户端直接找到相应的OSS,并提交I/O 请求;

    l OSS 找到对应的OST 进行文件读写,并返回给Lustre 客户端。

    2-10 Lustre 文件读写示意图

    1.2      Lustre I/O性能特点与最佳

    1 Lustre概述
    Lustre是面向集群的存储架构,它是基于Linux平台的开源集群(并行)文件系统,提供与POSIX兼容的文件系统接口。Lustre两个最大特征是高扩展性和高性能,能够支持数万客户端系统、PB级存储容量、数百GB的聚合I/O吞吐量。LustreScale-Out存储架构,借助强大的横向扩展能力,通过增加服务器即可方便扩展系统总存储容量和性能。Lustre的集群和并行架构,非常适合众多客户端并发进行大文件读写的场合,但目前对于小文件应用非常不适用,尤其是海量小文件应用LOSFLots Of Small Files)。Lustre广泛应用于各种环境,目前部署最多的为高性能计算HPC,世界超级计算机TOP 10中的70%TOP 30中的50%TOP 100中的40%均部署了Lustre。另外,Lustre在石油、天然气、制造、富媒体、金融等行业领域也被大量部署应用。

     

    2 Lustre Stripe
    Lustre采用对象存储技术,将大文件分片并以类似RAID0的方式分散存储在多个OST上,一个文件对应多个OST上的对象。Lustre系统中,每个文件对应MDT上的一个元数据文件,inode以扩展属性记录了数据分片布局信息,包括stripe_count(对象数), stripe_size(分片大小), stripe_offset(起始OST)以及每个OST对象信息。当客户数据端访问文件时,首先从MDS请求文件元数据并获得分片布局信息(stripe layout),然后直接与多个OST同时交互进行并发读写。Lustre这种数据分片策略,提高了多用户访问的并发度和聚合I/O带宽,这是Lustre获得高性能的主要因素。再者,Stripe还能够使得Lustre可以存储超大文件,突破单一OST对文件大小的限制。当然,数据分片策略同时也会带来负面影响,比如增加系统负载和数据风险。

     

    LustreOST数量可以达到数千,但是出于复杂性、性能、实际存储需求等考虑,目前设计实现中将单个文件对象数限制为160个。对于EXT4后端文件系统,单个文件最大可达2TB,因此Lustre单个文件最大可以达到320TB。那么,Lustre如何在可用OST集合中选择合适的OST呢?目前有两种选择算法,即Round-Robin和随机加权算法,这两种算法调度的依据是,任意两个OST剩余存储容量相差是否超过20%的阈值。一般在系统使用之初,直接使用Round-Robin算法以顺序轮转方式选择OST,这种算法非常高效。随着文件数据量的增加,一旦达到20%的阈值,Lustre将启用随机加权算法选择OSTLustre维护着一个剩余空间的优先列表,采用随机算法在此列表中选择OST,这种算法会产生开销并影响性能。如果任意两个OST剩余存储容量相差重新降到20%阈值之内,则重新启用Round-Robin算法选择OSTLustre在创建文件时就按照分片模式并采用OST选择算法,预先创建好文件所需的OST对象。分片模式可以使用lfs setstripe进行设置,或者由系统自动选择缺省模式,文件目录会自动继承父目录的分片模式,但可以进行修改。数据写入后,文件分片模式就不能修改,新加入的OST只会参与新创建的文件目录OST选择调度。Lustre目前还没有实现OST存储空间的自动均衡,需要手工进行数据迁移复制达到均衡的效果。

     

    Lustre缺省情况下,stripe_count = 1, stripe_size = 1MB, stripe_offset = -1,即每个文件仅包含一个OST对象,分片大小为1MB,起始OSTLustre自动选择。实际上这种分片模式就是不对文件进行分片存储,显然不能满足许多应用的存储需求,实际应用时需要在分析数据特点、网络环境、访问行为的基础上进行适当配置。分片不是越多越好,在满足存储需求的前提下,应该使得OST对象数量尽可能少。应用lustre Stripe时,应该考虑如下因素:
    1提供高带宽访问Lustre文件分片并存储于多个OSS,对于单一大文件来说,它可以提供远大于单一OSS提供的聚合I/O带宽。在HPC环境中,成百上千的客户端会同时并发读写同一个文件,当文件很大时,分散与多个OSS能够获得非常高的聚合带宽。Lustre文件系统理论上可以提供2.5 TB/s的带宽,经过验证的带宽达到240 GB/s。当然对于小于1GB的文件来说,分片数量不宜多于4个,更多分片不会带来更高的性能提升,还会引入额外开销。对于小文件,文件大小本身可能小于分片大小,实际上是不作分片,对性能不会有提升。
    2改善性能。如果聚合的客户端带宽超过单个OSS的带宽,文件分片存储策略可以充分利用聚合的OSS带宽,极大提高性能,为应用程序提供高速的数据读写访问。合理的分片数量可以估算,客户端聚合I/O带宽除以单个OSS I/O性能即可得到。
    3提供超大容量文件Lustre后端文件系统采用改进的EXT3文件系统(接近于EXT4),单个文件最大为2TB。如果不进行分片,则单个Lustre文件最大只能为2TBLustre目前分片最多可达到160个,因此文件最大可以达到320TB,这是容量是非常大的,基本上可以满足所有单一文件存储容量的需求。
    4提高存储空间利用率。当Lustre剩余存储空间有限时,每个OSS的剩余空间也就更加有限,这时再写入一个的大文件至单一OSS很大可能会由于空间不足而失败。采用分片策略,写入单个OSS的对象容量会成倍减小,如果OSS数量选择合适,文件仍然可以写入Lustre系统。这使得Lustre存储空间利用更为充分,有效提高了利用率。
    5增加负载Stripe会导致额外的锁和网络操作消耗,比如stat, unlink,虽然这些操作可以并发执行,但仍会对性能产生影响。另外,分片多会造成服务器的开销。设想这样一个情形:Lustre中有100OSS100个客户端,100个文件,每个客户端访问一个文件。如果不分片,则每个客户端仅与一个OSS相互,可以进行顺序I/O读写。如果每个文件分成100片,则每个客户端都需要分别与100OSS进行相交,并发访问时,OSS上的磁盘I/O为随机读写。这些都是额外的负载开销,一定程度上影响性能。
    6增加风险。从概率的角度看,多个OSS发生故障的概率要高出单个OSS许多。文件分片存储于多个OSS上,一个分片不可用就会导致整个文件不可访问,即使其他分片仍然是完好的。因此,分片大大增加了数据发生丢失的风险,需要采用适当的措施进行保护,比如RAID5/6或者Failover

     

    3 Lustre I/O性能特征

    1写性能优于读性能
    Lustre系统中通常写性能会优于读性能。首先,对于写操作,客户端是以异步方式执行的,RPC调用分配以及写入磁盘顺序按到达顺序执行,可以实现聚合写以提高效率。而对于读,请求可能以不同的顺序来自多个客户端,需要大量的磁盘seekread操作,显著影响吞吐量。其次,目前Lustre没有实现OST read cache,仅仅在客户端实现了Readahead。这样的设计也是有充分理由的,每个OST有可能会有大量客户端并发访问,如果进行数据预读,内存消耗将会非常大,而且这个是不可控制的。Writecache是在客户端上实现的,内存占用不会太大并且是可控的。再者,对于TCP/IP网络而言,读会占用更多的CPU资源。读操作,Lustre需要从网络接口缓存进行数据Copy而获得所需数据,而写操作可以通过sendfileZero Copy避免额外的数据复制。

    2大文件性能表现好
    Lustre的元数据与数据分离、数据分片策略、数据缓存和网络设计非常适合大文件顺序I/O访问,大文件应用下性能表现非常好。这些设计着眼于提高数据访问的并行性,实现极大的聚合I/O带宽,这其中关键得益于数据分片设计(具体见上面的分析)。另外,后端改进的EXT3文件系统本身也非常适合大文件I/O

    3小文件性能表现差
    然而,Lustre的设计却非常不利于小文件I/O,尤其是LOSFLots of small files)。Lustre在读写文件前需要与MDS交互,获得相关属性和对象位置信息。与本地文件系统相比,增加了一次额外的网络传输和元数据访问开销,这对于小文件I/O而言,开销是相当大的。对于大量频繁的小文件读写,Lustre客户端Cache作用会失效,命中率大大降低。如果文件小于物理页大小,则还会产生额外的网络通信量,小文件访问越频繁开销越大,对Lustre总体I/O性能影响就越大。OST后端采用改进的EXT3文件系统,它对小文件的读写性能本身就不好,其元数据访问效率不高,磁盘寻址延迟和磁盘碎片问题严重。这也是大多数磁盘文件系统的缺点,Reiserfs是针对小文件设计的文件系统,性能表现要好很多。Lustre的设计决定了它对小文件I/O性能表现差,实际I/O带宽远低于所提供的最大带宽。在4OSS的千兆网络配置下,单一客户端小文件读写性能不到4MB/s

     

    4 Lustre小文件优化
    实际上前面已经提到,Lustre并不适合小文件I/O应用,性能表现非常差。因此,建议不要将Lustre应用于LOSF场合。不过,Lustre操作手册仍然给出了一些针对小文件的优化措施。
    1)通过应用聚合读写提高性能,比如对小文件进行Tar,或创建大文件或通过loopback mount来存储小文件。小文件系统调用开销和额外的I/O开销非常大,应用聚合优化可以显著提高性能。另外,可以使用多节点、多进程/多线程尽可能通过聚合来提高I/O带宽。
    2)应用采用O_DIRECT方式进行直接I/O,读写记录大小设置为4KB,与文件系统保持一致。对输出文件禁用locking,避免客户端之间的竞争。
    3)应用程序尽量保证写连续数据,顺序读写小文件要明显优于随机小文件I/O
    4OST采用SSD或更多的磁盘,提高IOPS来改善小文件性能。创建大容量OST,而非多个小容量OST,减少日志、连接等负载。
    5OST采用RAID 1+0替代RAID 5/6,避免频繁小文件I/O引起的数据校验开销。

    Lustre提供了强大的系统监控与控制接口用于进行性能分析与调优,对于小文件I/O,也可以通过调整一些系统参数进行优化。
    1)禁用所有客户端LNET debug功能:缺省开启多种调试信息,sysctl -w lnet.debug=0,减少系统开销,但发生错误时将无LOG可询。
    2)增加客户端Dirty Cache大小:lctl set_param osc./*.max_dirty_mb=256,缺省为32MB,增大缓存将提升I/O性能,但数据丢失的风险也随之增大。
    3)增加RPC并行数量:echo 32 > /proc/fs/lustre/osc/*-OST000*/max_rpcs_in_flight,缺省为8,提升至32将提高数据和元数据性能。不利之处是如果服务器压力很大,可能反而会影响性能。
    4)控制Lustre stripinglfs setstripe -c 0/1/-1 /path/filename,如果OST对象数大于1,小文件性能会下降,因此将OST对象设置为1
    5)客户端考虑使用本地锁:mount -t lustre -o localflock,如果确定多个进程从同一个客户端进行写文件,则可用localflock代替flock,减少发送到MDSRPC数量。
    6)使用loopback mount文件:创建大Lustre文件,与loop设备关联并创建文件系统,然后将其作为文件系统进行mount。小文件作用其上,则原先大量的MDS元数据操作将转换为OSS读写操作,消除了元数据瓶颈,可以显著提高小文件性能。这种方法应用于scratch空间可行,但对于生产数据应该谨慎使用,因为Lustre目前工作在这种模式下还存在问题。操作方法如下:
     dd if=/dev/zero of=/mnt/lustre/loopback/scratch bs=1048576 count=1024
     losetup /dev/loop0 /mnt/lustre/loopback/scratch
     mkfs -t ext4 /dev/loop0
     mount /dev/loop0 /mnt/losf

     

    5 Lustre I/O最佳实践
    Lustre具有鲜明的I/O特点,并具有非常高的扩展性和大文件I/O性能。如果进行适当的配置和操作,Lustre则会展现更高的性能。下面给出一些Lustre I/O最佳实践,可根据实际应用情况择优实践。
    1)使用单进程读取完整的共享小文件,需要时传输数据至其他进程。
    2)使用单进程访问容量在(1MB, 1GB)之间的小文件,将文件OST对象数设为1
    3)使用单进程访问大于1GB的中等文件,文件OST对象数不超过4个。
    4)远大于1GB的大文件OST对象数应设为>4,这种文件不要采用顺序I/Ofile-per-processI/O访问模式。
    5)限制单个目录下的文件数量,包含大量小文件的目录stripe_count设置为1
    6)小文件存放在单一OST上,单进程文件创建和读写性能会得到提高。
    7)包含大量小文件的目录存放在单一OST上,文件创建性能会提到极大提升。
    8)尽量避免频繁地打开和关闭文件。
    9)仅在必要时使用ls -l,它会与所有相关的OST交互,操作代价很大,尽可能使用lslfs find代替。
    10)考虑使用I/O中间件来改善性能,如ADIOSHDF5MPI-IO

     

    6 Lustre深入阅读
    [1] Luster: http://www.lustre.org
    [2] Lustre 2.0 Operations Manual http://wiki.lustre.org/manual/LustreManual20_HTML/index.html
    [3] Understanding Lustre Internals http://wiki.lustre.org/images/d/da/Understanding_Lustre_Filesystem_Internals.pdf
    [4] Lustre Architecture ftp://ftp.uni-duisburg.de/Linux/filesys/Lustre/lustre.pdf
    [5] Lustre White Paper http://www.raidinc.com/pdf/whitepapers/lustrefilesystem_wp.pdf
    [6] Lustre Sources: https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=LUSTRE-185-G-F@CDS-CDS_SMI

    展开全文
  • 为了解决相应的编程和执行效率问题,异构并行编程模型已被广泛使用和研究.从异构并行编程接口与编译/运行时支持系统两个角度总结了异构并行编程模型最新的研究成果,它们为异构架构和上层应用带来的技术挑战提供了...
    摘要:近年来,异构系统硬件飞速发展.为了解决相应的编程和执行效率问题,异构并行编程模型已被广泛使用和研究.从异构并行编程接口与编译/运行时支持系统两个角度总结了异构并行编程模型最新的研究成果,它们为异构架构和上层应用带来的技术挑战提供了相应的解决方案.最后,结合目前的研究现状以及异构系统的发展,提出了异构并行编程模型的未来方向.
    关键词: 异构并行编程模型     异构系统     GPU     编程接口     编译     运行时系统    
    Research on Heterogeneous Parallel Programming Model
    LIU Ying, LÜ Fang, WANG Lei, CHEN Li, CUI Hui-Min, FENG Xiao-Bing    
    Abstract: With the recent development on heterogeneous hardware, heterogeneous parallel programming model has been widely used with the intension of simplifying programming and improving efficiency. This paper analyses latest achievements in heterogeneous parallel programming interfaces and runtime supporting systems, and solutions to new problems brought by heterogeneous architectures and various applications. In the end, some future trends in this area are discussed.
    Key words: heterogeneous parallel programming model     heterogeneous system     GPU     programming interface     compile    runtime system    

    近年来,处理器从单核转变到多核,芯片的并行计算能力得到增强,性能显著提高[12].然而,由于结构复杂,传统处理器遭遇了严重的功耗瓶颈,无法通过增加核数继续带来性能提升.在这样的背景下,出现了CPU与一个或多个加速设备在片上或主板上相互连接组成的异构系统,以进一步增强计算能力:CPU作为控制设备,负责复杂的控制、调度等工作;而加速设备则负责大规模的并行计算或专业领域的计算任务.加速设备通常在指令集、微结构、功能或计算能力等方面与CPU有很大区别,GPU是目前最为常见的加速设备之一.GPU在片上集成了几十甚至上百个每指令耗能(energy per instruction,简称EPI)较低的简单核[3456],它不包含分支预测、乱序执行等耗费资源的模块,借助高度的并行性隐藏单个任务的延迟,达到远高于CPU的计算吞吐量.除GPU外,可重构硬件(如FPGA)也常作为加速设备.目前,异构系统已十分普遍,遍布于服务器、个人电脑、嵌入式终端中,异构系统通过高速互联相互连接可构成异构集群,而异构集群通过互联网络连接在一起可构成大规模的云服务环境,如图 1所示.在2013年6月发布的超级计算机Top500排名中,前10名中有4个采用了异构架构[7],其中,排名第一的天河2号是由Intel通用处理器与MIC(many integrated core)架构协处理器构成的异构集群.

    Fig. 1 Cloud computing enviroment based on heterogeneous system图 1 基于异构系统的云服务环境

    在硬件异构设备与架构逐渐普遍化的同时,上层应用的需求也发生了巨大改变:大数据的出现,带来了大量高并发、低计算密度的应用[89];云计算的兴起,则带来了数量繁多的非传统服务[10].这些应用不再单纯地追求处理速度,而是在同时处理大量数据以及在可忍受的时间内提供服务方面有更多诉求.这些诉求与CPU对单个任务快速响应的特征并不一致,迫切需要微结构与CPU不同的加速设备协助完成.

    异构系统的发展,伴随着新兴应用的需求,使原有的并行编程模型(例如OpenMP,Cilk等)不再适用,直接推动了异构并行编程模型的研究.近几年,研究人员开展了大量的工作,例如:2007年,NVIDIA提出的CUDA[11];2008年,Khronos Group提出的OpenCL[12];2011年,PGI等公司提出的OpenAcc[13];2008年,Intel提出的Merge[14];2010年,IBM提出的Lime[15];2012年,微软提出的C++AMP[16]等,都是面向异构系统的并行编程模型.

    本文第1节概述异构架构与上层应用带来的技术挑战,介绍异构并行编程模型的发展历程,并对其编程接口、编译/运行时支持机制研究中的关键技术进行简要介绍.第2节和第3节分别详细介绍这两个研究领域中的最新研究成果,并归纳研究现状.第4节总结并讨论异构并行编程模型的未来发展趋势.

    1 异构并行编程模型概述

    异构并行编程模型是异构系统与上层应用之间的桥梁,与传统并行编程模型一样,它的设计也需要考虑任务划分、任务映射、数据分布、同步、通信5个关键因素[17].然而在异构架构的背景下,这些关键因素的作用范围有所扩大或改变,因此,传统并行编程模型在异构系统中不再适用,需要进行异构并行编程模型的研究.同时,新兴应用也为异构并行编程模型提出了新的挑战.

    1.1 异构并行编程模型面临的技术挑战1.1.1 异构架构带来的技术挑战

    异构并行编程模型的一个重要任务是:为程序员提供一个合理的硬件平台抽象,使其在编程时既可以充分利用丰富的异构资源、又不必考虑复杂的硬件细节.然而,异构系统与传统的同构系统相比,在设备内部微结构、设备间互联架构两方面都更加复杂化和多样化,这使得异构并行编程模型在建立平台抽象方面遇到了巨大的困难,在任务划分、任务映射、数据分布、同步、通信5个方面都面临着新的技术挑战.

    1) 任务划分与任务映射面临的新问题:异构系统中设备之间并行计算能力不同.

    同构系统中的计算设备为完全相同的多核CPU,尽管同一CPU不同核之间、同一核内的SIMD部件等可承担粒度不同的并行计算任务,但是不同设备具有相同的微结构,其并行计算能力是完全相同的.而在异构系统中,不同设备(如CPU与GPU,FPGA)的微结构具有本质差异,其并行计算模式与并行计算能力完全不同,设备的特长也完全不同,如图 2所示.这种设备间并行计算能力的差异,使得任务映射与任务划分不再是均一的,而是具有显著特异性的,这也更利于表达实际应用的特点.

    Fig. 2 Different computing devices present different parallel computing abilities in heterogeneous system图 2 异构系统中设备间并行计算能力不同

    2) 数据分布与通信面临的新问题:异构系统中加速设备内数据分布可配置、设备间数据通信渠道多样.

    从编程模型的角度看,同构系统中,CPU片内存储是软件透明的cache结构,片外存储则遵从共享内存模型,除访问延迟可能不同(例如NUMA架构)之外,不存在其他的差异性.因此在同构系统中,数据仅可分配在片外内存中,具有存储位置单一的特点,也不需要进行显式通信.但在异构系统中,加速设备片内通常包含软件可分配的快速局部存储(如SPM);而设备间的连接方式则差异很大,目前,CPU与一个或多个加速设备多数通过PCIe连接,也有将它们集成在一个芯片内的尝试,例如AMD提出的HSA(heterogeneous system architecture)[18],这使得加速设备可能无法采用与CPU相同的方式完成地址映射,导致它们的虚存空间分立,存在某一设备无法访问另一设备片外存储的问题.因此在异构系统中,数据可以被分配在CPU和加速设备片外内存、加速设备片内多层次局部存储等多个位置,数据分布问题变得十分复杂;设备间的数据通信也可能需要显式进行,如图 3所示.

    Fig. 3 Data layouts are configurable and communication paths vary in heterogeneous system图 3 异构系统中数据存储位置可配置、通信渠道多样

    3) 同步操作面临的新问题:异构系统中多层次数据共享位置及多范围同步操作.

    如前所述,异构系统中数据可以分布在多个存储位置上,使得同步操作需要在众多位置上保证共享数据的一致性.同时,由于异构系统的不同设备具有不同的并行计算能力,并行任务将以更加差异化的形式分布在整个系统中,这使得同步操作的范围变得十分复杂.此外,GPU等加速设备通常具有局部硬件同步机制,这也使得异构系统中的同步操作形式更加多样.

    1.1.2 上层应用带来的技术挑战

    从上层应用的角度来看,用户希望以接近自然语言的表达方式编写程序,近年来出现的Map Reduce[19]等编程框架,就更加符合人类的思维方式.然而,异构架构使得这种前进发生了严重倒退,带来了以下两个技术挑战:

    1) 缺乏良好的异构抽象及统一的编程接口.

    目前,通用CPU编程通常使用Java,Python等高级语言,GPU编程通常使用C的变体,而FPGA等可重构硬件设备通常使用Verilog或VHDL等硬件描述语言,这导致在异构系统中程序员无法使用统一的接口编写程序.

    2) 应用程序的性能优化难度显著增加.

    同构系统中,已有许多面向特定应用领域的并行优化,程序员可以直接调用这些优化接口.然而,异构系统中的加速设备种类繁多,例如,不同的FPGA可能具有编码/解码、流量控制、消息转发等特定功能,目前还没有足够多的工作为这些加速设备分别提供像在CPU上那样完善的并行优化,因此,程序员没有现成的接口可以使用,必须亲自在任务划分、任务映射、数据分布、同步与通信5个方面仔细权衡,程序优化难度极大.

    1.2 异构并行编程接口与编译/运行时支持机制概述

    异构并行编程模型依靠编程接口及编译/运行时系统解决上述技术挑战:异构并行编程接口是编程模型暴露给程序员使用的界面,它既需要为程序员提供合理的异构架构抽象,使程序员可以对异构计算资源加以合理利用,又需要保证接口的易用性,避免程序员陷入复杂的硬件细节中;编译/运行时系统是异构并行编程模型的软件工具层,它将程序员编写的加速器代码编译为可执行文件,并通过运行时系统完成任务的加速执行.

    异构并行编程接口可以为任务划分、任务映射、数据分布、通信、同步这5个关键因素中的4个提供保障,提供显式的任务划分、数据分布与通信和同步机制.然而,程序员通常更专注于所编写的应用的特点,从这个角度来看,只有显式的任务划分机制对于程序员来说是必不可少的,而数据分布与通信、同步机制在一定程度上增加了程序员的编程负担.

    异构编译/运行时支持机制的主要任务是保障任务映射,即,任务具体在哪个设备或计算单元上执行、以何种顺序执行.同时还负责对任务划分、数据分布与通信、同步等机制进行全系统级别的优化.

    综上所述,异构并行编程模型依靠编程接口以及编译/运行时系统来解决异构系统中的新问题.其中,异构并行编程接口主要解决任务划分问题,同时为数据分布与通信、同步提供保障;而编译/运行时系统主要解决任务映射问题,同时为系统进行性能优化.

    1.3 异构并行编程模型的发展

    异构并行编程模型是随着GPU的发展而兴起的,由于GPU保留了许多流式处理器的特征,因此早期的异构并行编程模型(例如2004年出现的BrookGPU[20])秉承了流式编程思想.流(stream)是这类编程模型的核心, stream是一组数据的集合,计算在stream的每个数据元素上并行执行,符合单指令多数据(SIMD)或多指令多数据(MIMD)的执行模式.然而,SIMD或MIMD对stream中每个数据元素的操作在控制流上是完全相同的,这虽然符合多数流媒体应用的特点,但是对范围更为广泛的数据并行应用来说要求过于苛刻.在这种背景下,伴随着NVIDIA GPU在商业上获得的巨大成功,2007年出现的CUDA得到了大力推广,它以单程序多数据(SPMD)的形式表达数据并行性:同一段操作作用在不同数据上时,不必采取控制流中完全相同的路径.然而,CUDA仅能在以NVIDIA GPU为加速设备的异构系统中使用,于是,2008年底出现了多家公司共同制定的跨平台异构并行编程框架标准OpenCL,它适用于任何并行系统.OpenCL将实际的硬件平台抽象为一个统一的平台模型,这也是OpenCL与CUDA最大的不同.但是CUDA和OpenCL的编程接口都较为低级,程序员的编程效率不高,其原因首先是遗产代码需要重新改写,其次是它们基于C语言进行扩展,Java,Python等更高级的语言无法使用这种扩展.针对遗产代码的问题,2011年出现了OpenAcc异构并行编程模型,它支持在遗产C/Fortran代码上直接加入制导命令;而针对Java,Python程序员使用异构计算平台困难的问题,2010年~2011年就出现了Copperhead[21], Lime等编程接口与Java/Python类似的异构并行编程模型以及JOCL[22],JCUDA[23],PyCUDA[24],PyOpenCL[25]等辅助工具.

    2 异构并行编程接口研究

    异构并行编程接口的研究,致力于解决第1.1.1节所述的异构架构带来的3个技术挑战,同时为上层应用提供统一的编程接口.因此,异构并行编程接口需要将图 2和图 3所示的异构架构特征体现出来,同时尽量降低编程难度.针对异构架构带来的3个技术问题,异构并行编程接口的研究可以分为异构任务划分机制、异构数据分布与通信机制、异构同步机制这3个方向,下面将分别介绍这3个方向的研究成果.

    2.1 异构并行编程接口的分类

    异构并行编程接口从接口形式的角度可以划分为两类:一类是新的异构并行编程语言,一类是现有语言的异构并行扩展.对现有语言进行异构并行扩展,可以通过库(library)或制导(directive)的方式,它们通常基于C/ Java/Python等应用范围较广泛的语言.其中,基于Python/Java的新语言或语言扩展通常更容易掌握和使用,属于较为高级的异构并行编程接口;而基于C的新语言或语言扩展通常编程复杂,属于较为低级的异构并行编程接口.从异构并行编程接口的功能来说,也大致可以分为两类:有些编程接口屏蔽了较多的异构系统硬件细节,通常仅为程序员显式提供异构任务划分机制,而异构数据分布与通信机制以及异构同步机制由运行时系统完成,使程序员编程效率有所提高;而有些编程接口将多数异构系统的硬件细节通过上述机制暴露给程序员使用,为程序员编程及优化带来更大自由度,但同时也带来一些使用上的困难,降低了效率.

    图 4给出的异构并行编程接口的分类示意图中,空心圆代表新的异构并行编程语言,斜线圆代表现有语言的异构并行扩展;纵坐标表明了编程接口的形式:类似于Python,Java或C/C++;而横坐标体现了编程接口的功能:屏蔽了较多硬件细节的编程接口以任务划分为主,而暴露这些细节的编程接口则显式提供任务划分、数据分布与通信、同步等多种机制.

    Fig. 4 Classification of heterogeneous parallel programming interfaces图 4 异构并行编程接口的分类

    具体地说,在类Python和类Java类别中,Copperhead是一种新的异构并行编程语言,是Python的子集;Garg等人[26]提出的编程接口属于现有语言的扩展,在Python的基础上增加了一些注释;IBM提出的Lime属于新的异构并行编程语言,兼容Java.它们与Python/Java类似,易于使用且无需程序员进行显式的数据分布、通信与同步操作,属于较为高级的异构并行编程接口.在类C/C++类别中,Intel提出的Merge是一种采用Map Reduce模式的新的异构并行编程语言;微软提出的C++AMP是C++11的异构扩展,更偏重于利用C++语言标准中的特性支持异构编程;Stanford提出的BrookGPU是一种新的异构并行编程语言,采用流式编程思想.它们都在一定程度上简化了数据分布、通信与同步,相对容易编程.OpenACC基于C/Fortran进行了异构扩展,支持在串行源程序中添加制导命令;NVIDIA的CUDA目前使用得最为广泛,它属于C语言的异构扩展,为程序员提供大量API.它们都需要程序员显式地进行任务划分、数据分布与通信、同步等操作,编程难度较大.为了解决这个问题,出现了诸如hiCUDA[27],CUDA-lite[28],OpenStream[29]等基于CUDA的改进的异构并行编程模型,它们对CUDA编程接口进行了简化,在一定程度上提升了编程效率,尤其是国内的国防科学技术大学提出的OpenStream融合了BrookGPU与CUDA的特点,使编程更加容易;OpenCL的使用也较为广泛,它打破了CUDA只能支持包含NVIDIA GPU的异构系统的局限,但也正因如此,程序员在使用OpenCL编写程序时需要进行额外的平台选取工作,使得编程更加复杂.

    2.2 异构任务划分机制

    在同构系统中,并行编程接口仅需提供面向单一设备的并行任务划分机制,例如任务并行、数据并行等.异构并行编程接口在此基础上还需要提供描述任务在不同设备(如CPU与GPU)间分配的机制,因此,异构并行编程接口的任务划分机制需包含“异构特征描述”以及“并行性表达”两个维度,其中,异构特征描述是异构并行编程模型不同于其他并行编程模型所特有的特征.

    Brook是Stanford大学2003年推出的一种流式编程语言,最初服务于Merrimac流式超级计算机和Imagine等流式处理器[30],后来增加了对GPU的支持,称为BrookGPU.在异构特征描述方面,BrookGPU采用特殊函数kernel来标明需要在GPU上执行的代码段,kernel函数必须作用于流(stream)上.在并行性表达方面,BrookGPU采用流式编程思想,通过stream表达了细粒度的数据并行.

    OpenCL/CUDA在C语言的基础上提供了异构扩展,它们的异构特征描述机制与BrookGPU的kernel函数类似.但在并行性表达方面,OpenCL/CUDA支持SPMD计算模型,而非流式编程思想.与BrookGPU的另一个不同之处是:除了数据并行之外,OpenCL还通过命令队列(command queue)提供了任务并行机制.hiCUDA是CUDA的扩展,其任务划分机制与CUDA相同,但是呈现给程序员的编程接口更加高级,可以直接在串行C代码上使用注释实现异构特征描述;进一步地,并行性表达也通过注释完成.

    Lime是新的异构并行编程语言,它通过语言结构为程序员提供了丰富的操作符用于任务的划分[31].在异构特征描述方面,Lime并没有显式的接口,这一点与BrookGPU,OpenCL/CUDA完全不同.其本质原因是因为Lime采用了基于任务的并行执行模型,而BrookGPU,OpenCL/CUDA则以数据并行为主.除任务并行之外,Lime在并行性表达方面也通过map/reduce操作符提供了细至中粒度的数据并行机制.

    Merge是一种新的异构并行编程语言,它基于Intel已有的异构多核多线程系统编程环境EXOCHI[32],采用Map Reduce思想,因此,它的异构编程接口与上述方式均不同.在异构特征描述方面,Merge提供了平台变体(target variant)机制,程序员需为异构系统中的不同设备提供不同版本的代码实现.在并行性表达方面,Merge可以描述完全独立的任务之间的并行性,但无法刻画它们之间的制约关系.Merge还通过粒度变体(granularity variant)构建了层次化的数据并行性,但是该机制无需程序员干预,因此它是一种层次较高的异构并行编程接口.

    C++AMP是C++的异构扩展,它利用C++11中的lambada表达式进行异构特征描述,标明程序员希望在加速设备上执行的代码;在并行性表达方面,C++AMP与OpenCL/CUDA的SPMD执行模式类似.

    Copperhead属于新的异构并行编程语言,在异构特征描述方面,它提供了@cu修饰符,用于标明需要在加速设备上执行的函数.在并行性表达方面,它为程序员提供了数种并行原语,它们的操作对象都是一维数组,称为序列(sequence).Sequence可以嵌套,因此,Copperhead可以同时表达扁平的数据并行性和嵌套的数据并行性. Copperhead具有较高的编程效率,其平均代码量仅为CUDA程序的约四分之一.

    Garg等人在文献[26]中提出了一个面向Python程序的简单异构编程接口,它提供一个特殊的迭代器prange,用于表明该循环需要分配到加速设备上并行执行,以实现异构特征描述.在并行性表达方面,prange仅指明了该循环需要并行执行,该循环具体如何并行执行则由对应的编译和运行时支持系统完成.

    OpenAcc在C/Fortran上进行了异构扩展,它为程序员提供多组制导命令进行任务划分[33].在异构特征描述方面,OpenAcc支持并行区域(parallel region)与内核区域(kernel region),这两种区域将被加载到加速设备上执行.在并行性表达方面,OpenAcc提供了与OpenCL/CUDA类似的机制.

    国防科学技术大学提出的OpenStream是一种对OpenMP进行扩展的异构并行编程接口,它具有一组带有流处理特征的编译制导命令,融合了BrookGPU与CUDA的特点,提升了编程效率.

    2.3 异构数据分布与通信机制

    传统的并行编程模型主要关注共享存储平台,数据分为共享和私有两种存储属性,通过共享数据进行通信.然而在异构系统中,数据分布不仅具有共享和私有的属性,还需要指明分布在哪个设备上;数据通信也不再单一地通过共享数据方式来实现,而是增加了设备间显式数据传输方式.因此,异构数据分布机制可以划分为“设备间分布”和“设备内分布”两个维度,数据通信机制则主要依靠“显式传输”机制.

    BrookGPU中,加速设备处理的输入或输出即被定义为stream,体现设备间分布;而stream在CPU与加速设备之间的通信则依靠特定的接口函数完成,体现显式传输.

    OpenCL为存储在加速设备上的数据定义了特定的类型cl_mem,以体现设备间分布.同时,通过__global/__ local关键字分别指定数据分布在加速设备的共享存储和局部存储中,以体现设备内分布.数据通信则通过特定API完成,以体现显式传输.CUDA和hiCUDA也提供了与OpenCL功能类似的编程接口.

    尽管OpenCL/CUDA为程序员提供了丰富的异构数据分布与通信接口,但是普通程序员一般无法充分利用这些接口获得性能上的提升.这是因为加速设备通常设计了多种硬件加速机制,例如GPU的全局内存访存合并机制:如果程序员没有为数据分配合理的存储位置或者设定足够多的线程,就会导致无法进行加速,影响程序执行效率.为了解决这个问题,出现了基于CUDA的CUDA-lite,它允许程序员在CUDA程序中加入简单的制导语句,数据分布相关的优化工作依靠CUDA-lite运行时系统完成,从而降低了CUDA程序的编写难度.

    OpenAcc与OpenCL/CUDA的异构数据分布与通信机制大体类似,区别主要体现在:首先,在异构数据分布方面,OpenAcc允许程序员将数据分配在不同设备上,但是无法指定数据分配在加速设备的何种存储中,即,不具有设备内分布机制;其次,在异构通信机制方面,OpenAcc提供了在通信之前确定数据是否已在目的地存在的机制,保证仅在数据不存在的情形下进行数据传输,而OpenCL/CUDA没有相应机制.

    C++AMP提供了两个类,以分别标明数据仅存放于加速设备中或在CPU与加速设备间共享.这两个类体现了设备间分布,与OpenAcc类似.但是对于那些在CPU与加速设备间共享的数据,程序员无需显式地进行数据传输操作,而是由编译器和运行时系统自动地负责通信操作以及一致性保证的工作.因此,C++AMP节省了程序员的一部分编程工作,是比OpenCL/CUDA/OpenAcc等更加高级的异构并行编程接口.

    OpenStream与OpenCL/CUDA/OpenAcc均不同,它采用流结构进行加速设备中的数据管理,它在程序中定义了一个区域,描述相关的GPU数据流在程序中的生存周期,并给出在流结构内活跃的数据流.

    然而,由程序员指定数据存储的位置并显式地完成数据通信,会增加程序员的编程负担,降低编程效率,因此,较为高级的异构编程接口,如前述的Lime,Merge,Copperhead等,均不提供显式的异构数据分布与通信接口,而是依靠运行时系统代为完成这部分工作.

    2.4 异构同步机制

    同步机制与任务并行执行的模式息息相关,如前所述,异构任务划分机制与传统并行编程模型相比更加复杂,因此,异构同步操作的范围可以存在于设备间(如CPU与GPU并行任务之间)、加速设备内全局(如GPU内所有并行任务之间)、加速设备内局部(如GPU内部分并行任务之间),范围比同构系统更加多样.与同构系统一样,异构同步点也保证了指令执行的先后顺序,或维护了不同线程的内存视图一致.

    OpenCL提供了两种不同范围内的显式同步机制:第1种是加速设备内局部同步,它维护了一组线程内部共享数据的一致性;第2种是加速设备内全局同步,它保证了不同任务执行的先后顺序.

    与OpenCL不同,CUDA中的同步具有显式同步与隐式同步两种形式[34],且它们都属于加速设备内的局部同步.CUDA以thread/thread block/grid方式组织线程,且在程序执行过程中,一个thread block中线程号连续的数个thread将以SIMD模式执行,这些thread组成了一个warp.隐式同步是指:一个warp内部的各个thread在执行时是严格同步的,若存在没有执行完当前指令的thread,则任何thread都不会开始下一条指令的执行.显式同步是指:CUDA提供API用于完成一个thread block内部所有warp的同步.CUDA的隐式同步更强调相邻指令之间的执行顺序,而显式同步则强调thread block内部各个thread的内存视图一致.

    与OpenCL/CUDA仅提供加速设备内同步机制不同,OpenStream还提供设备间同步机制,即,显式的设备同步结构,用于CPU与GPU之间的同步.

    然而,更多异构并行编程接口并不提供任何显式同步机制,而是在程序中的特殊位置(通常是并行执行的循环迭代之间)设置隐式同步点.例如在OpenAcc中,并行区域包含的循环迭代间存在隐式的同步,但是程序员可以显式去除这些隐式同步点.文献[26]提出的Python的异构扩展接口没有提供显式的同步机制,但在每个prange标明的并行循环末尾都默认存在一个隐式的同步点;并行循环是可以嵌套的,但隐式同步点仅存在于最外层循环的末尾.显式同步点的减少,极大地减轻了编程负担,因此,多数高级异构并行编程接口都选择不提供或少提供同步操作.但是隐式同步给编译器分析程序带来了诸多困难,极易带来执行效率的下降.

    2.5 小 结

    本节详细介绍了异构并行编程接口在任务划分、数据分布与通信、同步操作这3个领域的最新研究成果,它们与传统并行编程接口之间存在着本质差异,为异构架构以及上层应用带来的技术挑战提出了部分解决

    方案:

    1) 在解决第1.1.1节所述的异构架构带来的3个新问题方面,异构并行编程接口具有如下特点:

    · 为了解决异构系统中设备间并行计算能力不同的问题,异构任务划分机制在传统并行编程模型的基础上增加了“异构特征描述”维度,用于描述任务在不同设备间的分配情况;

    · 为了解决异构系统中加速设备内数据分布可配置、设备间数据通信渠道多样的问题,异构数据分布和通信机制在传统并行编程模型的基础上增加了“设备内数据多层分布”维度和“设备间显式通信”接口,不同于利用共享数据进行通信的方式;

    · 为了解决异构系统中多范围同步操作的问题,异构同步机制在传统并行编程模型的基础上增加了“设备间同步”机制,同时,依据加速设备硬件特征,提供加速设备内的局部和全局同步.

    2) 在解决上层应用带来的新问题方面,异构并行编程接口侧重于解决统一的编程接口问题,它尝试着将多种设备上的编程接口通过“异构特征描述”融合起来.但是这个问题目前仍然没有完全得到解决,表现在多数异构并行编程接口需要使用特殊的方式编写加速设备代码.

    表 1总结了不同异构并行编程接口提供上述机制的方式.其中,

    *并行性表达一栏中,“数据”和“任务”分别代表数据并行和任务并行,其中,数据并行具有多种表达方式;

    数据分布一栏中,“设备间”代表CPU与加速设备间的数据分布,“设备内”代表加速设备内的数据分布;

    异构同步机制一栏中,“设备间”代表CPU与加速设备之间的同步,“全局”和“局部”分别代表加速设备内部的全局和局部同步.

    表 1可以看出:目前几乎所有的异构并行编程接口都提供显式的任务划分机制,且大多通过kernel函数标记加速设备代码;在异构数据分布机制方面,只有一半左右提供了显式接口用于表达数据在不同设备之间或加速设备内部的分布,而采用显式通信机制的并不占多数;在异构同步机制方面,只有少数显式提供了加速设备内部的局部同步操作,多数均选择隐式同步的方式.

    Table 1 Summary of heterogeneous parallel programming interfaces表 1 异构并行编程接口小结
    3 异构编译/运行时支持机制研究

    异构编译/运行时系统的研究,致力于解决第1.1.1节所述的异构架构带来的3个技术挑战以及上层应用带来的性能优化难度高的问题.具体地说,异构任务映射机制负责解决不同设备间并行计算能力不同的问题,将程序员划分好的并行任务映射到实际的物理计算单元中执行;异构编译/运行时优化负责解决性能优化难度高的问题,在数据分布可配置、通信渠道多样、多种同步范围的背景下,合理权衡异构系统整体资源利用率,提升程序性能.下面分别详细介绍异构任务映射机制及异构编译/运行时优化两个领域的研究成果.

    3.1 异构任务映射机制

    异构编译/运行时系统的任务映射机制有两类:一类是直接映射,即,独立完成并行任务向异构平台映射的工作;另一类是间接映射,即,需要借助其他异构编译/运行时系统协助完成部分任务映射工作.直接映射机制通常在运行时系统中实现,而间接映射机制则采取编译时源到源变换与运行时分析相结合的方式实现.

    图 5给出的异构编译/运行时系统的分类示意图中,纵坐标体现了运行时系统任务映射机制的不同.采取直接映射机制的并行编程模型,一般由工业界的知名公司提出并维护,例如Intel的Merge、微软的C++AMP、NVIDIA的CUDA和以AMD为代表进行推广的OpenCL,它们通常针对特定的异构系统进行任务映射与优化,有相应的硬件产品支撑.采用间接映射机制的并行编程模型,则通常选取工具链较为成熟、应用较为广泛的其他异构并行编程模型作为辅助,目前选择CUDA,OpenCL的居多,图 5标明了采用间接映射的异构并行编程模型分别利用哪种其他的编程模型实现任务映射的大致情况.

    Fig. 5 Classification of heterogeneous runtime systems图 5 异构运行时系统的分类
    3.1.1 直接映射机制

    OpenCL的任务映射机制相对简单,这是因为OpenCL编程接口为程序员提供了一个平台模型,把实际的异构系统抽象为具有统一的架构:异构系统由主机(host)与加速设备(device)构成,其中,加速设备可以是多个.每个加速设备包括数个结构一致的计算单元(compute unit,简称CU),而每个CU由数个结构一致的PE(processing element)构成.OpenCL kernel映射到device上执行:一个CU执行一组并行的线程,每个PE执行一个线程.因此, OpenCL可适用于任意异构系统 ,只需将异构系统实际的硬件架构与OpenCL平台模型对应起来即可,这也是OpenCL与只能应用于以NVIDIA GPU为加速设备的异构系统中的CUDA最大的不同.

    与OpenCL相比,Merge的任务划分及映射工作较为复杂,需要将程序员使用Map Reduce函数编写的程序动态地映射到异构系统中合适的设备上执行,映射时的重要工作是确定粒度.如前所述,Merge提供了granularity variant机制,但是程序员无需确认实际粒度的大小;Merge运行时系统采用轮廓分析(profiling)的方式确定粒度:程序在不同设备上分别使用数量较少的数据点执行一次,记录它们的相对性能数据,并据此为不同的设备选择不同数目的数据点.

    针对加速设备包含向量执行部件(即SIMD部件)的异构系统,文献[35]提出了一种将OpenCL/CUDA这类SPMD程序变换为显式向量指令的方法,将kernel的计算任务映射到SIMD部件上.该方法的核心思想是:将几个相邻的kernel计算实例合并为一个向量操作,该方法将kernel函数作为一个整体,称为“全函数向量化”,它在程序的静态单赋值(static single assignment,简称SSA)[36]表示上进一步实施数据流分析,以明确并行数据的取值范围,用于保障SIMD部件所需的数据对齐、连续等约束,同时生成模板处理不同的控制流.

    针对包含多种微结构不同CPU(即,加速设备为CPU)的异构系统,文献[37]提出了一种将细粒度SPMD并行程序映射到粗粒度并行计算部件上的编译优化方法,通过将细粒度的CUDA线程编译为多线程C程序完成异构任务映射,并实施了线程聚合等相关优化.

    针对加速设备具有复杂局部存储的异构系统(例如IBM CELL),文献[38]提出了一种OpenCL程序任务映射的方法,该方法依靠用户不可见的运行时辅助线程(opencl runtime thread,简称ORT)完成任务的映射与调度工作.具体地说,ORT创建并管理一个命令调度器以确定命令执行的顺序,再依据每个任务的类型,将其发射到不同的部件中执行:在任务发射、切换、完成时,由ORT启动软件模拟的内存操作,对局部存储中的数据进行额外处理,以保证程序语义的正确.在这样的基本任务映射机制下,还进行了线程聚合、预取等优化.

    针对包含FPGA的异构系统,文献[39]提出了一种OpenCL程序任务映射方法,可适用于CPU-GPU-FPGA异构架构以及嵌入式SOC(system on chip)中处理器-FPGA的异构架构,这两种异构架构涵盖了目前主流的包含FPGA加速设备的异构平台.在任务映射方面,一个OpenCL Work-Group将映射至FPGA中Processing Array上的一个Processing Row上执行,一个Processing Row中包含数个物理Processing Element,可以用于执行work- item.除此之外,实现任务在FPGA上直接映射的相关工作还包括FCUDA[40],SOpenCL[41],OpenRCL[42],FSM SYM Builder[43],O4F[44]等.

    3.1.2 间接映射机制

    Lime通过编译时将Lime程序变换为Java bytecode以及OpenCL代码,并利用OpenCL运行时的方式来完成任务映射.如前所述,Lime并未提供任务划分相关的编程接口,因此,任务划分与映射是Lime运行时系统的主要工作.Lime运行时系统首先识别出没有副作用的任务,作为可在加速设备上执行的基本单位;之后,对任务的计算量进行评估,优先选取计算较为密集的任务;最后扫描任务内部代码,挖掘其数据并行模式,并将其转换为对应的OpenCL代码.这样,Lime就可以通过JNI调用OpenCL代码,进一步利用OpenCL运行时系统完成余下的任务映射工作.

    Copperhead通过将Copperhead程序变换为CUDA程序,并利用CUDA运行时的方式来完成任务映射,嵌套数据并行的Copperhead程序被映射为CUDA中层次化的grid/thread-block/thread并行执行机制.文献[26]也类似地采用了变换为CUDA程序的方式.作为CUDA的扩展,hiCUDA,CUDA-lite也利用CUDA完成间接映射;而OpenStream则依据平台的不同,分别变换为BrookGPU和CUDA程序.与上述系统相比,OpenAcc的映射方式Planner[45]相对更为成熟:它依据NVIDIA GPU的硬件结构特点指导OpenAcc并行循环到CUDA kernel的变换,使得映射后GPU全局内存与局部存储之间数据移动最少、浪费带宽的非连续全局内存访问最少,同时整个GPU的并行性最大化.因此,Planner在完成OpenAcc任务映射的同时,也进行了全系统优化.

    在采用流式编程思想的编程模型中,BrookGPU的任务映射机制是依靠将kernel变换为Cg shader来完成的,其输入和输出的stream都被存放在GPU的纹理存储中.而Sponge[46]是一个将StreamIt[47]程序变换为CUDA程序的异构编译/运行时系统.StreamIt是一种平台结构无关的流式编程语言,其主体是相互隔离的计算单元actor, actor分为不具并行性的stateful类型和具有数据并行性的stateless类型.在任务划分与映射方面,Sponge首先将stateful的actor分配给主机端的CPU,而stateless的actor则映射到GPU上执行.对于映射到GPU上执行的actor, Sponge进一步地将它们分为计算型和访存型两个类别,并分别依据GPU局部存储和线程数目确定它们的并行粒度,最终映射成相应的CUDA代码.类似地,国内的清华大学也在文献[48]中进行了将StreamIt扩展至异构平台的支持与优化工作.

    针对已有的并行编程语言,文献[49]提出了一种将传统的OpenMP程序变换为OpenCL程序、并利用OpenCL运行时的方法,同时,动态地实施了数据传输优化,并采用决策树预测的方式在多种平台上获取最佳性能.与之类似的工作有文献[50]提出了将串行的C程序通过多面体优化技术变换为CUDA程序以及文献[51]提出了将OpenMP程序变换为CUDA程序的工具OpenMPC.

    上述工作在加速设备内部不同计算单元间的任务映射方面进行了深入研究,而文献[52]提出了一种不同设备之间(例如CPU与GPU)任务映射与调度的运行时机制MDR(model driven runtime),MDR以SLAC(suitability, locality,availability,criticality)为准则,将DAG图上的任务调度到CPU或GPU上执行.更宏观地,文献[53]提出了一种异构系统的运行时框架Harmony,其基本思想是:执行在异构平台上的每个应用,都具有一个控制线程负责将计算任务(kernels)分配到不同的设备上,其执行方式与串行指令序列在现代超标量乱序处理器中的执行方式相同:kernels对应于指令,而异构系统中的不同设备对应于处理器中的不同功能部件.Harmony为任务并行程序在异构计算平台上提供了一个清晰、有效的执行方式.

    3.2 异构编译/运行时优化

    与同构平台类似,异构编译/运行时优化有两条途径:一是平台相关优化,其核心是挖掘系统硬件优势;二是应用导向优化,其核心是实施特定领域的优化并解决应用的输入敏感问题.但是在具体的优化技术和手段方面,由于硬件结构的差异,它们与同构平台上的优化有较大差别,下面分别介绍这两方面的研究成果.

    3.2.1 平台相关优化

    在全系统的优化方面,文献[54]提出:异构系统通常具有复杂且多变的硬件结构,因此程序员仅负责编写正确实现程序功能的代码、由编译/运行时系统完成面向加速设备结构特点的优化是比较合理的方式,这样也有利于程序在不同异构系统中获得良好的性能.文章提出:对于OpenCL/CUDA程序,程序员可以仅实现kernel函数的功能,而任务划分、数据分布等复杂但与性能高度相关的问题由编译/运行时系统实施的相关优化来完成,这些优化包括:自动向量化、访存合并、线程/线程块合并、预取、调整数据布局等.

    在异构同步机制优化方面,文献[55]讨论了CUDA程序在其他异构平台上执行时的同步问题.如前所述, CUDA中的同步有显式与隐式两种形式,其中,隐式同步是由GPU硬件来实现机制保证的.在这种情形下,如果将CUDA程序移植到其他平台执行,程序就可能会因为缺乏硬件保证的隐式同步机制而产生错误.文章作者发现并深入研究了这个问题,将其等价转换为数据依赖关系的问题,并依据传统的数据流分析技术提出了解决方案.国内的解放军信息工程大学也在文献[56]中进行了CUDA程序隐式同步检测的研究.

    在异构数据分布与通信优化方面,文献[57]提出了一种CPU-GPU之间数据传输管理工具CGCM(CPU GPU communication manager),以自动进行设备间的数据传输:CGCM首先通过类型推断机制将数据结构划分为非指针和指针两种,并对它们分别进行生存区间分析和指向分析;之后,分别为活跃变量、活跃指针插入CPU-GPU/ GPU-CPU数据传输操作或地址映射函数.在此基础上,CGCM还进行了运行时的数据传输优化,消除CPU与GPU之间的环状数据传输.然而,由于CGCM依赖类型推断机制,导致它不能处理递归的数据类型.因此,研究者们对CGCM进行了改进,提出了DyManD(dynamically managed data)[58],它将CPU与GPU内等价的内存单元分配在等价的内存位置上,而不再需要CGCM中的别名分析,更具实用性.类似地,国内的华中科技大学也在文献[59]中进行了CUDA程序中自动管理数据传输操作的相关研究.在异构数据分布与通信优化方面的工作还有:文献[60]提出了一种将OpenCL在不支持硬件缓存一致性的众核系统(例如Intel SCC)中执行时的运行时优化方法,该方法建立了任务划分与数据传输之间关系的代价模型,以在运行时动态地选择数据传输代价最低意义下的最优任务划分模式.

    3.2.2 应用导向优化

    在提升特定领域应用性能方面,中国科学院软件研究所在文献[61]和文献[62]中分别提出了一种跨平台的傅立叶变换自动优化机制以及一种跨平台的图像积分图算法优化方法.它们分别针对实际程序特征、面向AMD和NVIDIA GPU实施了提高片外访存带宽利用率以及计算资源利用率的多种优化,并将其封装为库,供程序员使用.中国科学院计算技术研究所在文献[63]中提出了一种面向GPU的BLAS库自动优化方法,该方法结合NVIDIA GPU的结构特征进行了并行任务重组、循环剥离及填充等优化,极大地降低了线性代数相关优化的难度.文献[64]提出了一种跨平台的稀疏矩阵向量乘算法的优化机制,它首先将问题抽象为多种版本的OpenCL kernel,之后,在运行时自动依据不同的平台选择合适版本的kern el执行:不同版本kernel包含向量化加速、访存对齐、并行任务重组等不同优化.此外,在信息通信、生物蛋白质、地球物理学等领域的应用中进行异构编译及运行时优化的相关工作还有文献[656667].总之,这些工作的共同特点是:依据特定领域的应用特征、结合专家的专业知识实施优化,可以显著降低相关应用的优化难度,减轻程序员的优化负担.

    在解决应用的输入集敏感问题方面,文献[68]提出了G-ADAPT机制,使得同一程序在接收不同输入时均可获得良好的性能.G-ADAPT首先在给定的GPU程序上实施多种优化,并分别收集不同输入特征下的性能数据,存入数据库;然后,采用统计学习的方法从该数据库中得出程序输入与程序优化之间的关系;最后,在运行时判断实际输入属于何种类别,并动态实施相关程序优化,保障执行效率.与G-ADAPT采用的模式识别机制不同,文献[69]提出了一种分段式的运行时优化方法:编译器首先判断一个GPU kernel的类型,然后实施有针对性的优化,并将kernel实施该优化前后的执行时间估计为一个输入集的函数.若该函数显示该优化在所有输入集范围内都是有益的,那么就完全实施优化;若该优化仅在部分输入集范围内是有益的,就生成两个版本的代码,分别对应于实施该优化的输入集范围与不实施优化的输入集范围.这样,在kernel上对所有输入集敏感型优化进行处理后,将生成多个版本的优化kernel,对应于不同的输入集范围.之后,运行时将依据实际的输入集,从多版本优化kernel中选择一个合适的版本,并发射到GPU上执行.

    3.3 小 结

    本节详细介绍了异构编译/运行时支持系统在任务映射机制以及系统优化两个领域最新的研究成果,它们比传统并行编程模型的运行时技术更加复杂,为异构架构以及上层应用带来的挑战提出了部分解决方案.

    1) 在解决第1.1.1节所述的异构架构带来的3个新问题方面,异构编译/运行时系统进行了以下工作:

    · 为了解决异构系统中设备间并行计算能力不同的问题,异构任务映射机制研究如何将任务自动地分配到不同设备上执行,目前,研究较为广泛的加速设备包括GPU、多核CPU、FPGA、SIMD加速部件、含有复杂局部存储的专用设备(如IBM CELL/Intel SCC)等,它们多数是传统同构并行编程模型的运行时系统无法掌控或较少使用的计算资源;

    · 为了解决异构系统中加速设备内数据分布可配置、设备间数据通信渠道多样、同步范围复杂的问题,异构编译/运行时优化在细粒度计算任务的分配、多种数据存储与通信、共享与同步等方面都有相关研究工作,其中,数据分布与通信相关的研究最为广泛和深入.与传统的基于共享内存的粗粒度并行优化相比,异构编译/运行时优化需要处理的资源更丰富、结构更复杂,因此方法更加多样,但成熟度不高.

    2) 在解决上层应用带来的新问题方面,异构编译/运行时系统侧重于解决性能优化困难的问题,它通过平台相关优化和应用导向优化,自动地为程序员更合理地组织代码、发挥硬件资源优势,同时,将专业领域的常用方法与异构资源一一对应、精细调优,并封装为库,供程序员使用.然而,与传统的并行编程模型运行时优化相比,由于异构系统中资源的多样性以及异构并行编程接口的复杂性,异构编译/运行时技术还不够成熟,需要在全系统资源优化方面进一步加以研究.

    4 结论和未来的挑战

    异构并行编程模型的出现是为了解决异构架构和上层应用带来的技术挑战,它在异构并行编程接口和编译/运行时系统方面都与传统的数据并行编程模型、任务并行编程模型具有显著的区别,这是由异构系统丰富的硬件资源决定的.近年来,在异构并行编程模型的研究方面,国内外学术界与工业界的知名研究团队或公司都投入了大量的精力,取得了有价值的研究成果,例如国外的Stanford,Princeton,UIUC,UC Berkeley,Purdue等,国内的国防科学技术大学、清华大学、华中科技大学、中国科学院软件研究所和中国科学院计算技术研究所等,工业界的Intel,AMD,NVIDIA,IBM等.

    4.1 结 论

    当前,异构并行编程模型的研究是通过异构并行编程接口和异构编译/运行时系统解决异构架构以及上层应用带来的技术挑战的,具体地说:

    1) 异构架构带来的技术挑战是,不同的并行计算能力、多层次可配置的数据存储及多种通信渠道、多层次数据共享及多范围同步操作这3个新问题.异构并行编程接口分别通过相应的3个机制解决上述问题,其中,异构任务划分机制是核心,余下的两个问题有接近一半的异构并行编程模型选择通过异构编译/运行时系统解决;异构编译/运行时系统通过异构任务映射机制解决并行计算能力不同的问题,并且通过平台相关优化综合利用上述资源,提升系统性能.总体来说,目前在利用异构架构中特定加速设备方面研究已经较多,关注度较高的加速设备包括:多核CPU、SIMD加速部件、GPU、FPGA以及含有局部存储的专用设备(例如IBM CELL/Intel SCC)等,其中,以GPU相关的平台优化研究得最为深入.但是,在合理利用异构架构中的多种加速设备以及自动选择加速设备方面,目前研究得还比较少.

    2) 上层应用带来的技术挑战是,缺乏统一的编程接口以及程序性能调优难度增大.异构并行编程接口负责提供异构平台抽象,它将异构架构中的资源进行封装供程序员使用,提供统一的编程接口;异构编译/运行时系统则通过应用导向优化为程序员提供相关领域帮助,降低性能优化难度.总体来说,尽管上层应用已经可以通过多种异构并行编程模型实现对异构资源的合理利用,但是目前异构抽象并不能完全屏蔽复杂的硬件细节,同时优化协助尚不全面,编写和优化程序仍然具有较高难度.

    总之,当前异构并行编程模型的研究中成果较多的领域是异构并行编程接口中的任务划分机制以及异构编译/运行时中的任务映射机制和特定加速设备优化;而成果较少的领域是异构并行编程接口中的数据分布与通信机制和同步机制以及异构编译/运行时系统中的多加速设备/异构系统优化和应用导向优化.因此,目前程序员可以使用高层编程接口编写异构程序,并在特定加速设备上获得较高的执行效率;但是异构并行程序的编写难度明显大于传统并行程序,且缺乏多加速设备混合平台的高效执行手段.

    4.2 未来的挑战

    随着异构架构越来越普遍和成熟以及云计算与大数据等新兴应用的异军突起,结合当前异构并行编程模型的研究现状,我们认为,未来的研究将面临如下技术挑战:

    1) 面向普通用户的异构并行编程接口.

    尽管目前的异构并行编程接口已经可以为程序员提供一个基本统一的编程环境、一个抽象的异构平台,但是程序员仍然需要了解一些复杂的硬件细节才能完成程序编写,例如任务划分粒度、数据通信等,异构程序的编写具有很高难度.此外,专业领域的异构编程缺乏良好的环境,目前还只能借助库的方式减轻编程负担,没有类似于Erlang[70]这样专用的异构编程接口.因此,建立更简洁的异构抽象、同时为多种特定领域提供专用编程接口,是未来研究的重要方向.

    2) 面向多种加速设备的异构编译/运行时优化.

    异构系统的优势在于集中了多种不同特征的计算资源,因此多加速设备的异构系统将逐渐成为主流,例如同时包含GPU,FPGA的异构系统,或同时包含不同微结构CPU的异构系统等.现有的工作多集中在面向单一加速设备的编译/运行时优化方面,并已经取得了一些成果.但是多加速设备方面的相关研究还不多,运行时系统需要研究如何结合不同加速设备的结构特点,自动地将代码调度到合适的加速设备上执行.

    3) 面向异构集群的异构并行编程模型.

    与现有的单节点异构系统不同,异构集群的异构性存在于节点内部以及节点之间,异构并行编程模型需要考虑范围更广的异构性,从节点内合理地扩展到节点间,形成全系统的编程环境.尽管当前多数研究还仅限于单节点异构系统,但在异构集群方面已经出现了一些初步研究:SnuCL[71]是一种基于OpenCL的扩展的编程框架,MATE-CG[72]和MapCG[73]是带有异构扩展的Map Reduce编程模型,它们都是CPU/GPU异构混合集群系统中的编程环境.

    总之,随着异构架构以及上层应用的发展,异构并行编程模型正步入编程接口更简单、编译/运行时系统更灵活的发展阶段,如何提供合理的平台抽象、依据实际应用和实际平台提供高效优化以及向规模更大的异构集群扩展,是未来研究的重点.

    参考文献
     
    [1] Dongarra J. The promise and perils of the coming multicore revolution and its impact. CTWatch Quarterly, 2007,3(1):1-33.
    [2] Wang L, Cui HM, Chen L, Feng XB. Research on task parallel programming model. Ruan Jian Xue Bao/Journal of Software, 2013, 24(1):77-90 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/4339.htm
    [3] Grochowski E, Annavaram M. Energy per instruction trends in Intel microprocessors. Technology@Intel Magazine, 2006,4(3):1-8.
    [4] Annavram M, Grochowski E, Shen J. Mitigating Amdahl’s law through EPI throttling. In: Proc. of the 32th ACM/IEEE Int’l Symp. on Computer Architecture (ISCA). 2005. 298-309 .
    [5] Grochowski E, Ronen R, Shen J, Wang H. Best of both latency and throughput. In: Proc. of the 22nd IEEE Int’l Conf. on Computer Design (ICCD). 2004.236-243 .
    [6] Lee VW, Kim C, Chhugani J, Deisher M, Kim D, Nguyen AD, Satish N, Smelyanskiy M, Chennupaty S, Hammarlund P, Singhal R, Dubey P. Debunking the 100x GPU vs. CPU myth: An evaluation of throughput computing on CPU and GPU. In: Proc. of the 37th ACM/IEEE Int’l Symp. on Computer Architecture (ISCA). 2010. 451-460 .
    [7] Top500 list. 2013. http://www.top500.org/list/2013/06/
    [8] Yan XF, Zhang DX. Big data research. Computer Technology and Development, 2013,23(4):168-172 (in Chinese with English abstract).
    [9] Meng XF, Ci X. Big data management: Concepts, techniques and challenges. Journal of Computer Research and Development, 2013,50(1):146-149 (in Chinese with English abstract).
    [10] Li Q, Zheng X. Research survey of cloud computing. Computer Science, 2011,38(4):32-37 (in Chinese with English abstract).
    [11] NVIDIA CUDA toolkit. 2013. https://developer.nvidia.com/cuda-downloads
    [12] KHRONOS Group. The open standard for parallel programming of heterogeneous systems. 2013.http://www.khronos.org/opencl
    [13] OpenAcc: Directives for accelerators. 2013. http://www.openacc-standard.org/
    [14] Linderman MD, Collins JD, Wang H, Meng TH. Merge: A programming model for heterogeneous multi-core systems. In: Proc. of the 13th Int’l Conf. on Architectural Support for Programming Languages and Operating Systems (ASPLOS). 2008. 287-296 .
    [15] Auerbach J, Bacon DF, Cheng P, Rabbah R. Lime: A Java-compatible and synthesizable language for heterogeneous architectures. In: Proc. of the 2010 ACM Int’l Conf. on Object Oriented Programming Systems Languages and Applications (OOPSLA). 2010. 89-108 .
    [16] Microsoft Corporation. C++ AMP: Language and programming model. Version 1.0, 2012.
    [17] Asanovic K, Bodik R, Catanzaro BC, Gebis JJ, Husbands P, Keutzer K, Patterson DA, Plishker WL, Shalf J, Williams SW, Yelick KA. The landscape of parallel computing research: A view from Berkeley. Technical Report, UCB/EECS-2006-183, Berkeley: University of California, 2006.
    [18] Kyriazis G. Heterogeneous system architecture: A technical review. AMD, 2012. http://amd-dev.wpengine.netdna-cdn.com/ wordpress/media/2012/10/hsa10.pdf
    [19] Dean J, Ghemawat S. MapReduce: Simplified data processing on large clusters. Communications of the ACM, 2008,51(1): 107-113 .
    [20] Buck I, Foley T, Horn D, Sugerman J, Fatahalian K, Houston M, Hanrahan P. Brook for GPUs: Stream computing on graphics hardware. ACM Trans. on Graphics (TOG), 2004,23(3):777-786 .
    [21] Catanzaro B, Garland M, Keutzer K. Copperhead: Compiling an embedded data parallel language. In: Proc. of the 21st ACM SIGPLAN Symp. on Principles and Practice of Parallel Programming (PPoPP). 2011. 47-56 .
    [22] Jocl.org—Java bindings for OpenCL. 2010. http://www.jocl.org/
    [23] Jcuda.org—Java bindings for CUDA. 2012. http://www.jcuda.org/
    [24] PyCUDA. 2013. http://mathema.tician.de/software/pycuda/
    [25] PyOpenCL. 2009. http://mathema.tician.de/software/pyopencl/
    [26] Garg R, Amaral NG. Compiling python to a hybrid execution environment. In: Proc. of the 3rd Workshop on General-Purpose Computation on Graphics Processing Units (GPGPU). 2010. 19-30 .
    [27] Han TD, Abdelrahman TS. hiCUDA: High-Level GPGPU programming. IEEE Trans. on Parallel and Distributed Systems, 2011, 22(1):78-90 .
    [28] Ueng SZ, Lathara M, Baghsorkhi SS, Hwu WW. CUDALite: Reducing GPU programming complexity. In: Proc. of the 21st Workshop on Languages and Compilers for Parallel Computing. 2008. 1-15 .
    [29] Tang T. Research on programming model and compiler optimizations for CPU-GPU heterogeneous parallel systems [Ph.D. Thesis]. Changsha: Graduate School of National University of Defense Technology, 2011 (in Chinese with English abstract).
    [30] Stanford University. Brook language. 2003.http://graphics.stanford.edu/projects/brookgpu/lang.html
    [31] Dubach C, Cheng P, Rabbah R, Bacon DF, Fink SJ. Compiling a high-level language for GPUs (via language support for architectures and compilers). In: Proc. of the ACM SIGPLAN 2012 Conf. on Programming Language Design and Implementation (PLDI). 2012. 1-11 .
    [32] Wang PH, Collins JD, Chinya GN, Jiang H, Tian X, Girkar M, Yang NY, Lueh GY, Wang H. EXOCHI: Architecture and programming environment for a heterogeneous multi-core multithreaded system. In: Proc. of the ACM SIGPLAN 2007 Conf. on Programming Language Design and Implementation (PLDI). 2007. 156-166 .
    [33] The OpenACC™ application programming interface. Version 2.0, 2013.http://www.openacc.org/sites/default/files/OpenACC.2.0 a_1.pdf
    [34] NVIDIA Corporation. CUDA C programming guide. Version 5.5, 2013.
    [35] Karrenberg R, Hack S. Whole-Function vectorization. In: Proc. of the 9th Int’l Symp. on Code Generation and Optimization (CGO). 2011. 141-150 .
    [36] Alpern B, Wegman MN, Zadeck FK. Detecting equality of variables in programs. In: Proc. of the 15th ACM SIGPLAN-SIGACT Symp. on Principles of Programming Languages (POPL). 1988. 1-11 .
    [37] Stratton JA, Grover V, Hwu WW, Marathe J, Aarts B, Murphy M, Hu Z. Efficient compilation of fine-grained SPMD-threaded programs for multicore CPUs. In: Proc. of the 8th Int’l Symp. on Code Generation and Optimization (CGO). 2010. 111-119 .
    [38] Lee J, Kim J, Seo S, Kim S, Park J, Kim H, Dao TT, Cho Y, Seo SJ, Lee SH, Cho SM, Song HJ, Suh SB, Choi JD. An OpenCL framework for heterogeneous multicores with local memory. In: Proc. of the 19th Int’l Conf. on Parallel Architectures and Compilation Techniques (PACT). 2010. 193-204 .
    [39] Chin SA. Reusable OpenCL FPGA infrastructure [MS. Thesis]. Toronto: Electrical and Computer Engineering University, 2012.
    [40] Papakonstantinou A, Gururaj K, Stratton JA, Chen D, Cong J, Hwu WW. FCUDA: Enabling efficient compilation of CUDA kernels onto FPGAs. In: Porc. of the 7th IEEE Symp. on Application Specific Processors (SASP). 2009. 35-42 .
    [41] Owaida M, Bellas N, Daloukas K, Antonopoulos CD. Synthesis of platform architectures from OpenCL programs. In: Proc. of the 2011 IEEE Int’l Symp. on Field-Programmable Custom Computing Machines (FCCM). 2011. 186-193 .
    [42] Lin M, Lebedev I, Wawrzynek J. OpenRCL: Low-Power high-performance computing with reconfigurable devices. In: Proc. of the 2010 Int’l Conf. on Field Programmable Logic and Applications (FPL). 2010. 458-463 .
    [43] Cartwright E, Ma S, Andrews D, Huang MQ. Creating HW/SW co-designed MPSoPC’s from high level programming models. In: Proc. of the 2011 Int’l Conf. on High Performance Computing and Simulation (HPCS). 2011. 554-560 .
    [44] Ahmed T. OpenCL framework for a CPU, GPU, and FPGA platform [MS. Thesis]. Toronto: University of Toronto, 2011.
    [45] Wolfe M. Implementing the PGI accelerator model. In: Proc. of the 3rd Workshop on General-Purpose Computation on Graphics Processing Units (GPGPU).2010. 43-50 .
    [46] Hormati A, Samadi M, Woh M, Mudge T, Mahlke S. Sponge: Portable stream programming on graphics engines. In: Proc. of the 16th Int’l Conf. on Architectural Support for Programming Languages and Operating Systems (ASPLOS). 2011. 381-392 .
    [47] Thies W, Karczmarek M, Amarasinghe S. StreamIt: A language for streaming applications. In: Proc. of the 2002 Int’l Conf. on Compiler Construction (CC). Berlin, Heidelberg: Springer-Verlag, 2002. 179-196.
    [48] Wang B. Heterogeneous platform research based on StreamIt compiler [Ph.D. Thesis]. Beijing: Tsinghua University, 2011 (in Chinese with English abstract).
    [49] Grewe D, Wang Z, O’Boyle MFP. Portable mapping of data parallel programs to OpenCL for heterogeneous systems. In: Proc. of the 11th Int’l Symp. on Code Generation and Optimization (CGO). 2013. 1-10 .
    [50] Baskaran MM, Ramanujam J, Sadayappan P. Automatic C-to-CUDA code generation for affine programs. In: Proc. of the 2010 Int’l Conf. on Compiler Construction (CC). 2010. 244-263 .
    [51] Lee S, Min SJ, Eigenmann R. OpenMP to GPGPU: A compiler framework for automatic translation and optimization. In: Proc. of the 14th ACM SIGPLAN Symp. on Principles and Practice of Parallel Programming (PPoPP). 2009. 101-110 .
    [52] Pienaar JA, Raghunathan A, Chakradhar S. MDR: Performance model driven runtime for heterogeneous parallel platforms. In: Proc. of the Int’l Conf. on Supercomputing (ICS). 2011. 225-234 .
    [53] Diamos G, Yalamanchili S. Harmony: An execution model and runtime for heterogeneous many core systems. In: Proc. of the 17th Int’l Symp. on High Performance Distributed Computing (HDPC). 2008. 197-200 .
    [54] Yang Y, Xiang P, Kong JF, Zhou HY. A GPGPU compiler for memory optimization and parallelism management. In: Proc. of the ACM SIGPLAN 2010 Conf. on Programming Language Design and Implementation (PLDI). 2010. 86-97 .
    [55] Guo ZY, Zhang EZ, Shen XP. Correctly treating synchronizations in compiling fine-grained SPMD-threaded programs for CPU. In: Proc. of the 20th Int’l Conf. on Parallel Architectures and Compilation Techniques (PACT). 2011. 310-319 .
    [56] Yue F, Pang JM, Zhao RC. Detecting and treatment algorithm of implicit synchronization based on dependence analysis in SPMD program. Ruan Jian Xue Bao/Journal of Software, 2013,24(8):1775-1785 (in Chinese with English abstract).http://www.jos.org.cn/ 1000-9825/4343.htm
    [57] Jablin TB, Prabhu P, Jablin JA, Johnson NP, Beard SR, August DI. Automatic CPU-GPU communication management and optimization. In: Proc. of the ACM SIGPLAN’11 Conf. on Programming Language Design and Implementation (PLDI). 2011. 142-151 .
    [58] Jablin TB, Jablin JA, Prabhu P, Liu F, August DI. Dynamically managed data for CPU-GPU architectures. In: Proc. of the 10th Int’l Symp. on Code Generation and Optimization (CGO). 2012. 165-174 .
    [59] Li B. Research on optimized programming for heterogeneous multi-core platform [Ph.D. Thesis]. Wuhan: Huazhong University of Science and Technology, 2011 (in Chinese with English abstract).
    [60] Lee J, Kim J, Kim J, Seo S, Lee J. An OpenCL framework for homogeneous manycores with no hardware cache coherence. In: Proc. of the 20th Int’l Conf. on Parallel Architectures and Compilation Techniques (PACT). 2011. 56-67 .
    [61] Li Y, Zhang YQ, Liu YQ, Long GP, Jia HP. MPFFT: An auto-tuning FFT library for OpenCL GPUs. Journal of Computer Science and Technology (JCST), 2013,28(1):90-105 .
    [62] Jia HP, Zhang YQ, Xu JL. Research on image integral algorithm optimization based on OpenCL. Computer Science, 2013,40(2): 1-7 (in Chinese with English abstract).
    [63] Cui HM, Wang L, Xue JL, Yang Y, Feng XB. Automatic library generation for BLAS3 on GPUs. In: Proc. of the IEEE Int’l Symp. on Parallel and Distributed Processing (IPDPS). 2011. 255-265 .
    [64] Su BY, Keutzer K. clSpMV: A cross-platform OpenCL SpMV framework on GPUs. In: Proc. of the Int’l Conf. on Supercomputing (ICS). 2012. 353-364 .
    [65] Datta D, Mehta S, Shalivahan, Srivastava R. CUDA based particle swarm optimization for geophysical inversion. In: Proc. of the 1st Int’l Conf. on Recent Advances in Information Technology (RAIT). 2012. 416-420 .
    [66] Fasih A, Hartley T. GPU-Accelerated synthetic aperture radar back projection in CUDA. In: Proc. of the 2010 IEEE Radar Conf. 2011. 1408-1413 .
    [67] Pavlović D, Vaser R, Korpar M, Šikić M. Protein database search optimization based on CUDA and MPI. In: Proc. of the 36th Int’l Convention on Information and Communication Technology Electronics and Microelectronics (MIPRO). Opatija: IEEE, 2013. 1278-1280.
    [68] Liu Y, Zhang EZ, Shen X. A cross-input adaptive framework for GPU programs optimization. In: Proc. of the IEEE Int’l Symp. on Parallel and Distributed Processing (IPDPS). 2009. 1-10 .
    [69] Samadi M, Hormati A, Mehrara M, Lee J, Mahlke S. Adaptive input-aware compilation for graphics engines. In: Proc. of the ACM SIGPLAN 2012 Conf. on Programming Language Design and Implementation (PLDI). 2012. 13-22 .
    [70] Erlang programming language. 1985. http://www.erlang.org/
    [71] Kim J, Seo S, Lee J, Nah J, Jo G, Lee J. SnuCL: An OpenCL framework for heterogeneous CPU/GPU clusters. In: Proc. of the Int’l Conf. on Supercomputing (ICS). 2012. 341-351 .
    [72] Jiang W, Agrawal G. MATE-CG: A MapReduce-like framework for accelerating data-intensive computations on heterogeneous clusters. In: Proc. of the IEEE Int’l Symp. on Parallel and Distributed Processing (IPDPS). 2012. 644-655 .
    [73] Hong CT, Chen DH, Chen YB, Chen WG, Zheng WM, Lin HB. Providing source code level portability between CPU and GPU with MapCG. Journal of Computer Science and Technology (JCST), 2012,27(1):42-56 .
    [2] 王蕾,崔慧敏,陈莉,冯晓兵.任务并行编程模型研究与进展.软件学报,2013,24(1):77-90. http://www.jos.org.cn/1000-9825/4339. htm
    [8] 严霄凤,张德馨.大数据研究.计算机技术与发展,2013,23(4):168-172.
    [9] 孟小峰,慈祥.大数据管理:概念、技术与挑战.计算机研究与发展,2013,50(1):146-149.
    [10] 李乔,郑啸.云计算研究现状综述.计算机科学,2011,38(4):32-37.
    [29] 唐滔.面向CPU-GPU异构并行系统的编程模型与编译优化关键技术研究[博士学位论文].长沙:国防科学技术大学,2011.
    [48] 王博.基于Streamit编译器的异构执行环境研究[博士学位论文].北京:清华大学,2011.
    [56] 岳峰,庞建民,赵荣彩.基于依赖分析的SPMD程序隐式同步检测及处理算法.软件学报,2013,24(8):1775-1785. http://www.jos. org.cn/1000-9825/4343.htm
    [59] 李波.基于异构多核平台的优化编程研究[博士学位论文].武汉:华中科技大学,2011.
    [62] 贾海鹏,张云泉,徐建良.基于OpenCL的图像积分图算法优化研究.计算机科学,2013,40(2):1-7.

    转载于:https://www.cnblogs.com/lifan3a/articles/4615151.html

    展开全文
  • 异构并行编程模型

    2015-06-26 17:18:00
    异构并行编程模型研究与进展[J].软件学报,2014, 25(7): 1459-1475.http://www.jos.org.cn/1000-9825/4608.html LIU Ying, LÜ Fang, WANG Lei, CHEN Li, CUI Hui-Min, FENG Xiao-Bing. Research on Heter...
  • 学习链接: 1、五种主要多核并行编程方法分析与比较 2、并行编程模型opencl、mpi、cuda等的区别
  • 1.目前两种重要的并行编程模型是数据并行和消息传递,数据并行模型的编程级别高,编程相对简单,但是它仅仅适用于数据并行问题;消息传递模型编程级别低,但具有更加广泛的扩展性。 2.数据并行模型即将相同的操作...
  • MapReduce并行编程模型

    千次阅读 2020-08-29 16:09:25
    MapReduce并行编程模型 1. MapReduce编程模型 MapReduce是采用一种分而治之的思想设计出来的分布式计算框架 如一复杂的计算任务,单台服务器无法胜任时,可将此大任务切分成一个个小的任务,小任务分别在不同的...
  • MapReduce是一种并行编程模型,用于大规模数据集的并行运算,那么MapReduce又是如何进行并行编程的呢? MapReduce采用“分而治之”的策略,将存储在分布式文件系统的大数据集切分成独立小数据块(即Split,分片),...
  • 并行编程模型汇总

    2012-11-14 23:38:09
    现行的并行编程模型.包括互联网应用和高性能计算。 高性能计算 (1)MPI,PGAS(如UPC,X10) (2)OpenMP DISC(Data intensive scalable computing) (1)MapReduce (2)Dryad (3)Pregel (4)...
  • 并行编程模型的研究

    千次阅读 2007-06-28 11:32:00
    并行编程模型 是并行计算,尤其是并行软件的基础,也是并行硬件系统的导向,在面临多核新挑战的情况下,什么样的并行编程模型在未来能成为主流,还很难说。至少到目前,还处于百家争鸣的时代,很多模型提出,很多在...
  • 并行编程模型之Actor/CSP/PGASActor1.背景2. 简介3.actor组成ActorMailbox邮箱behavior行为4.优势无锁异步隔离容错分布式5.劣势6.实践素数计算CSP1.简介2.CSP与go语言2.1 组成2.2Goroutine调度器3.Actor模型和CSP...
  • 并行是指同时发生的两个并发事件,具有并发的含义,而并发则不一定并行,也亦是说并发事件之间不一定要同一时刻发生。 3、并行性指两个或两个以上事件或活动在同一时刻发生。在多道程序环境下,并行性使多个程序...
  •  目前来说,单节点的并行编程模型有OpenMP、MPI等;集群上有MPI、UPC等。但是这些编程模型再带来某一些好处的同时,又带来了其他问题,所以如何设计一个能够让客户满意的编程模型,是一个非常艰难的工作。...
  • 一、MapReduce编程模型 - MapReduce是采用一种分而治之的思想设计出来的分布式计算框架 - 如一复杂或计算量大的任务,单台服务器无法胜任时,可将此大任务切分成一个个小的任务,小任务分别在不同的服务器上并行的...
  • 并行计算有助于应用和资源管理的合理化,但是为此方案找到找到合适的中间件却是很棘手的问题。Tom Nolle解释了应该寻找什么。 一些计算功能跟流程绑定得如此紧密,以至于如果可以(在处理器内核之间、CPU与GPU之间...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,924
精华内容 1,169
关键字:

并行编程模型