Aurora Exascale Architecture(PPT)2024

文摘   2024-08-05 08:00   山西  
演讲人:Servesh Muralidharan,计算机科学家,性能工程团队,美国阿贡国家实验室(ALCF)
时间:July 28 - August 9, 2024

会议:ATPESC 2024

接下来的三张幻灯片将依次介绍超级计算机、发展历程,以及美国能源部的百亿亿次级计算项目,其中Aurora是该项目的重要成果之一。

重点介绍超级计算机的组成,并强调过去十年中主要计算方式如何从向量处理器转向CPU和GPU。指出超级计算机不仅仅包含计算子系统。

超级计算机的构成要素
  • 处理器:架构设计优化以平衡复杂度、成本、性能和功耗。
  • 内存:通常采用商用DDR内存,容量受成本约束。
  • 节点:可集成多个处理器、内存和网络接口。
  • 网络:针对延迟、带宽和成本进行优化设计。
  • I/O系统:由复杂的存储、服务器和网络阵列组成。
  • 软件生态:包括编译器、库、工具、调试器等。
  • 控制系统:负责作业调度和系统管理。

Aurora的发展历程由来已久。重点介绍美国能源部的技术路线图,并说明Aurora从今年的ISC'24开始正式跻身百亿亿次级超算系统行列。

解析GPU的复杂结构及其在当前顶级超级计算系统中的性能主导地位。探讨芯片设计和制造工艺的创新,重点关注向Chiplet方向的发展,以PVC的复杂结构为例说明这类设备的特点。

从上到下解析Aurora硬件。

阐述Aurora的层级架构。从计算刀片开始,然后是网络交换机、机柜、网络拓扑结构,这些共同构成了Aurora系统的计算部分。还需要输入/输出节点和服务节点等辅助组件来支持整个系统的运行。

Aurora高级系统概述

  • 计算刀片

    • 2个Intel Xeon Max系列,带HBM

    • 6个Intel数据中心GPU Max系列

    • GPU:768 GB HBM

    • CPU:128 GB HBM,1024 GB DDR5

  • 交换刀片

    • 1个Slingshot交换机

    • 64个端口

    • Dragonfly拓扑

  • 计算机架

    • 64个计算刀片

    • 32个交换刀片

    • GPU:49.1 TB HBM

    • CPU:8.2 TB HBM,64 TB DDR5

  • AURORA系统

    • 系统服务节点(SSNs)

    • 用户访问节点(UANs)

    • DAOS节点(DNs)

    • 网关节点(GNs)

      • IOF服务,可扩展库加载

      • DAOS <-> Lustre数据移动

  • AURORA系统

    • 166个计算机架

    • 10,624个节点

    • GPU:8.16 PB HBM

    • CPU:1.36 PB HBM,10.9 PB DDR5

    • DAOS:64个机架,1024个节点,230 PB(可用),31 TB/s

强调ECB的聚合指标。接下来的几张幻灯片介绍每个组件。

这只是对组件的概述。后续幻灯片将详细介绍各个部分。探讨GPU作为性能关键因素,并提及其具体规格。解析各类Chiplet及其互连接口。为驱动这些GPU,我们需要SPR处理器及其PCIe输入/输出带宽。概括GPU之间的互连链路及其全互联设计。

深入探讨CPU,详细介绍其所有规格。重点说明SPR是一种多芯片结构,由四个通过一致性互连结构相连的计算象限组成。各种PCIe设备在平面上的不同位置与CPU的互连结构相连。这种设计在SNC4模式下本质上引入了NUMA距离,但默认的运行配置是Quad模式,使所有象限表现为一个整体。

概述架构的一些高级特性。展示Xe核心,它由8个向量引擎和8个矩阵引擎组成。以及一个512KB的L1缓存,可以配置为缓存或SLM。16个Xe核心组合在一起形成一个slice。4个slice与一个大型L2缓存、4个HBM2E内存控制器组合在一起形成一个Stack。一个或多个Stack可以在一个插槽上组合形成一个GPU。

演示GPU上的计算内核执行过程。首先描述GPU内核,解释它由工作项和工作组构成。GPU的第一个入口点是线程生成器,它将工作项和工作组划分为可映射到Xe核心(执行单元)的任务。每个Xe核心都有自己的线程调度器,然后在各自的计算管道上启动任务。所有互连GPU上的HBM具有统一的内存地址空间。每个Chiplet堆栈都有其本地三级缓存标记的HBM堆栈。例如,如果相邻的Chiplet请求内存访问,数据将先流向该HBM连接的Chiplet的三级缓存,然后再流向目的地。有专门的计算引擎,称为CCS,负责在Chiplet/堆栈上调度计算内核上下文。还有一组复制引擎,专门用于通过Xe链路在主机和GPU之间或GPU之间进行内存数据移动。

GPU计算执行流程
  • 在GPU上的执行从内存分配和计算内核调度开始。
  • GPU线程通过CCS生成和调度。
  • 当内核遇到“线程结束”指令时,执行停止。
  • 共享内存与设备内存分配导致数据访问延迟不同。
  • 当出现任何停滞条件时,GPU线程可以切换。但是,在执行过程中线程不能被中断。

介绍ECB如何安装在机架上。指出设计的复杂性和机架的密度。

强调Cassini网卡和Slingshot交换机。两者都是定制的专用集成电路。ECB和机柜中的组件采用直接液冷。存储或服务节点上的Slingshot网卡是风冷的PCIe适配器。

QoS – 流量类别类:缓冲区、队列和带宽的集合旨在通过流量整形提供应用间的隔离激进的自适应路由由于更接近的拥塞信息,预计对三跳Dragonfly更有效多级拥塞管理尽量减少拥塞应用对其他应用的影响极低的平均和尾部延迟高性能组播和规约。

这张幻灯片只是网络拓扑的概述,下一半的演示中有关于Dragonfly拓扑的更详细的幻灯片。重点讨论各种互连拓扑,以及每个超级计算机通常如何根据计算和I/O组件优化注入和切割带宽。

DAOS容量取决于用户选择的数据保护方式。EC16+2是一种具有16个数据块和2个校验块的纠删码(可在2次故障中保证数据安全)。总NVMe容量将是未经数据保护的DAOS容量。Optane持久内存用于存储元数据。NVMe的具体型号未公开。图片展示的是DAOS存储服务器(未显示NVMe设备)。

Aurora存储系统
  • DAOS提供Aurora的主要“平台”高性能存储系统。
  • Aurora利用现有的Lustre存储系统,Grand和Eagle,用于中心范围的数据访问和数据共享。
  • Intel Coyote Pass系统。
    • (2)Xeon 5320 CPU(Ice Lake)
    • (16)32GB DDR4 DIMMs
    • (16)512GB Intel Optane持久内存200
    • (16)15.3TB三星PM1733
    • (2)HPE Slingshot NIC
  • 1024台服务器
    • 每个节点将运行2个DAOS引擎
    • 2048个DAOS引擎

概念Aurora DAOS架构DAOS集成到Aurora高速Slingshot网络(蓝色平面)DAOS服务器用红色框表示灰色框代表计算机柜(非比例示意)。黄色框是提供访问Eagle和Grand的网关节点

在单个幻灯片上总结所有硬件规格,并介绍软件生态系统,下一组幻灯片将详细介绍。

  • 峰值性能

    • ≧ 2 Exaflops DP

  • 英特尔GPU

    • 英特尔® 数据中心 GPU

    • Max系列1550

  • 英特尔Xeon处理器

    • 英特尔® Xeon Max系列9470C

    • 带高带宽内存的CPU

  • 平台

    • HPE Cray-Ex

  • 计算节点

    • 2个英特尔® Xeon Max系列处理器

    • 6个英特尔® 数据中心GPU Max系列

    • 8个Slingshot11 fabric端点

  • GPU架构

    • 英特尔XeHPC架构

    • 高带宽内存

  • 节点性能

    • >130 TF

  • 系统规模

    • 166个机柜

    • 10,624个节点

    • 21,248个CPU

    • 63,744个GPU

  • 系统内存

    • 1.36PB HBM CPU容量

    • 10.9PB DDR5容量

    • 8.16PB HBM GPU容量

  • 系统内存带宽

    • 30.58PB/s 峰值HBM BW CPU

    • 5.95PB/s 峰值DDR5 BW

    • 208.9PB/s 峰值HBM BW GPU

  • 高性能存储

    • 230PB

    • 31TB/s DAOS带宽

    • 1024个DAOS节点

  • 系统互连

    • HPE Slingshot 11

    • 具有自适应路由的Dragonfly拓扑

  • 系统互连带宽

    • 峰值注入带宽 2.12PB/s

    • 峰值切割带宽 0.69PB/s

  • 网络交换机

    • 每个交换机25.6 Tb/s(64个200 Gb/s端口)

    • 每个方向的链接25 GB/s

  • 编程环境

    • C/C++,Fortran

    • SYCL/DPC++

    • OpenMP 5.0

    • Kokkos,RAJA

在单个幻灯片上涵盖所有编译器、库、框架、驱动程序堆栈。

在Aurora上,我们将支持多种GPU编程模型。包括随英特尔oneAPI软件提供的SYCL、OpenMP和OpenCL。此外,Aurora将提供Kokkos和RAJA。但是Aurora不会提供CUDA,因为CUDA是专有的。不过,CUDA的替代方案是HIP,最初为AMD GPU开发,目前正在进行工作,以在Aurora上提供实验版本。

讨论GPU感知的MPICH,支持通过PCIe在GPU和NIC之间以及通过Xelink在GPU之间无缝通信。

MPI
  • 基于开源MPICH,具备支持Aurora的新功能。
  • 利用OFI(开放式光纤接口)与Slingshot互连进行通信。
  • 重新设计以减少指令数量并消除不可扩展的数据结构。
  • 创新的集体算法针对Dragonfly网络拓扑进行了优化。
  • 对英特尔GPU具有感知能力。
    • 它构建在oneAPI Level Zero之上。
    • 支持点对点、单边和集体通信。
    • 通过Yaksa库支持不同的数据类型。
  • 英特尔GPU及节点内部GPU之间实现全互连。
  • 同一节点上配备多个网卡。
    • 将进程分配到网卡。
    • 条带化(单个进程通过多个网卡分发单条消息)。
    • 哈希(单个进程通过不同的网卡发送不同的消息,例如,取决于通信器或目标进程)。
    • 高效的多线程支持以使用多个网卡。

提到在如此大量节点上启动任务面临自身的挑战。提到PMIx(超大规模进程管理接口),它扩展了PMI接口。强调我们整体作业调度程序是PBS。

接下来的几张幻灯片是我对以下问题的看法:用户如何抽象Aurora超级计算机的数据流,以及如何设计应用代码或算法来缓解在如此大规模系统中编程时出现的瓶颈。

介绍HPC应用中的通信复杂性。讨论点对点与集体通信。提到HPCG基准示例。强调复杂的HPC应用通常适合某种通信模式。

HPC应用的通信复杂性
  • HPC应用展示了各种通信模式。
  • 系统中的问题分解对于避免负载不平衡至关重要。
  • 典型工作负载中的两种数据流设计。
    • 点对点
    • 集体
  • 应用运行时间的显著部分花费在通信调用上。
  • 执行工作负载时会出现特定模式。
  • 理解数据流对于性能效率至关重要。

介绍数据流架构背后的概念。提到CPU通常采用冯·诺依曼设计,并针对控制流进行优化。GPU优化了数据并行操作,但并非严格意义上的数据流架构,因为其中涉及一定的控制流。然而,理解数据流架构将帮助用户应用以数据流为中心的优化,以更好地扩展他们的工作负载。例如,在计算操作的局部最大值上并行化数据移动。这将防止局部资源饥饿,改善整体负载平衡和运行效率。

另一种视角:数据流设计
  • 优化数据流以实现可扩展计算。
  • 借鉴数据流计算机架构的概念,以理解逻辑限制。
    • 由内存操作的延迟驱动计算。
  • 设计和实现能最小化数据移动的算法。
  • GPU针对数据并行操作进行了优化。
  • CPU针对控制流进行了优化。
  • 识别通信模式。
  • 应用以数据流为中心的优化。

呈现数据在ECB上移动的设计概述

从CPU开始,解释一致性织物的复杂性,以及它通过信用来保证公平访问。

接下来提到通过MDFI在GPU的两个tile/stack之间的数据流设计。

现在讨论组件之间的数据移动。在进入CPU到NIC路径之前,解释PCIe交换机的作用。

现在开始引入CPU的DDR和NIC之间更细粒度的数据移动概念。讨论数据流在此路径上发生时显式跨越CPU象限。

现在进入CPU的DDR到GPU的HBM。提到数据局部性的重要性,因为如果有跨QPI路径,会涉及额外的延迟。讨论GPU的stack/tile 0上只有一个PCIe端点,因此相邻tile的内存需要通过MDFI、L3织物然后到HBM。

现在是NIC和GPU之间数据移动的最复杂示例。Aurora没有直接连接的GPU和NIC。数据移动需要通过PCIe接口一路到CPU的CHA织物。在软件中,这个机制称为“DMABuf”。

现在引入Xe链接的概念。强调这个链接是完全功能的织物,具有自己的链路层协议和SerDes(序列化器/反序列化器)。

由于双stack/tile设计,GPU的连接并不简单。连接是双平面架构,每个平面中的tile都是全互联的。由于GPU在ECB本身的物理放置限制,并不是所有tile0都是连接的。

详细讨论Dragonfly拓扑。分层设计,其中每个组可以使用特定拓扑。限制了整体跳数,同时显著减少所需的电缆长度。

回顾之前的图表,提到每个机柜上有本地交换机通过链路连接到计算节点。这8个机柜中的每一个都是全互联的,通过本地链路相连。然后每个交换机通过全局链路连接到这个本地组之外的其他机柜。

在这个图表上花费较多时间,将所有内容整合在一起。讲解数据从ECB上的GPU流向其中一个网络交换机的过程。然后指出它将如何通过本地或全局链路传输到适当的目的地。理解这种数据流将帮助应用更好地优化其代码以适应这种规模的系统。对于用户来说,在没有示例的情况下进行抽象是困难的,因此重新关联到数据流架构,并设想在此处进行类似的访问模式优化。


---【本文完】---

近期受欢迎的文章:

  1. Aurora未能获得Top500第一名的原因

  2. 美国《2021-2023财年开创未来高级计算生态系统发展报告:战略规划》

  3. CXL联盟主席:专有互连技术与CXL

  4. 总结:远观 ISC 2024

  5. 【论文】优化元数据交换:通过DAOS提升ADIOS元数据I/O性能



更多交流,可添加本人微信

(请附姓名/单位/关注领域)

IT奶爸
实践是检验“专家”的唯一标准。一群认真执着的IT奶爸的学习和分享。
 最新文章