在Perlmutter系统上编译使用CUDALibrarySamples中的cuFFTMp
背景介绍
cuFFTMp是NVIDIA提供的分布式快速傅里叶变换(FFT)库,它基于NVIDIA Collective Communications Library(NCCL)和NVIDIA SHMEM(NVSHMEM)实现,能够在多个GPU之间高效地进行FFT计算。Perlmutter是美国国家能源研究科学计算中心(NERSC)的超级计算机系统,配备了NVIDIA A100 GPU。
常见编译问题分析
在Perlmutter系统上编译使用cuFFTMp时,开发者经常会遇到两类典型的链接错误:
-
符号重复定义错误
当同时链接libnvshmem.a和libnvshmem_device.a时,会出现多个相同符号的定义冲突,这是因为这两个库包含了相同的设备端代码实现。 -
未定义引用错误
当没有正确链接NVSHMEM库或者链接顺序不当时,会出现各种NVSHMEM API的未定义引用错误,这表明链接器无法找到必要的NVSHMEM实现。
正确编译方法
经过NVIDIA开发者的验证,正确的编译命令应遵循以下原则:
-
仅使用设备端NVSHMEM库
避免同时链接libnvshmem.a和libnvshmem_device.a,只使用后者及其配套的主机端库。 -
正确的库链接顺序
cuFFTMp库(-lcufftMp)应该放在NVSHMEM库(-lnvshmem_device -lnvshmem_host)之前。 -
避免冗余链接
cuFFTMp已经包含了cuFFT的所有功能,因此不需要额外链接-lcufft。
示例编译命令:
CC -gpu=cc80 test_cufft.cu \
-I /opt/nvidia/hpc_sdk/Linux_x86_64/23.9/comm_libs/nvshmem/include/ \
-I /opt/nvidia/hpc_sdk/Linux_x86_64/23.9/math_libs/include/cufftmp \
-L /opt/nvidia/hpc_sdk/Linux_x86_64/23.9/math_libs/lib64 \
-L /opt/nvidia/hpc_sdk/Linux_x86_64/23.9/comm_libs/nvshmem/lib \
-Wl,-rpath,/opt/nvidia/hpc_sdk/Linux_x86_64/23.9/comm_libs/nvshmem/lib \
-lcufftMp -lnvshmem_device -lnvshmem_host
技术要点
-
NVSHMEM架构理解
NVSHMEM采用分离式设计,libnvshmem_host处理主机端通信,libnvshmem_device处理设备端通信。混合使用完整库和设备库会导致符号冲突。 -
库依赖关系
cuFFTMp依赖于NVSHMEM的特定API实现,正确的链接顺序确保解析依赖关系时能找到所有必要符号。 -
Perlmutter环境适配
使用-gpu=cc80标志指定A100 GPU的计算能力,确保生成代码能充分利用硬件特性。
实践建议
-
在Perlmutter系统上,建议使用模块环境管理不同版本的HPC SDK,避免路径硬编码。
-
对于复杂项目,考虑使用CMake等构建系统管理依赖关系和链接顺序。
-
开发过程中可以使用
nm工具检查库中的符号定义,帮助诊断链接问题。
通过遵循这些指导原则,开发者可以成功在Perlmutter系统上编译和运行基于cuFFTMp的应用程序,充分利用多GPU系统的计算能力进行大规模FFT计算。
kernelopenEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。C051
MiniMax-M2.1从多语言软件开发自动化到复杂多步骤办公流程执行,MiniMax-M2.1 助力开发者构建下一代自主应用——全程保持完全透明、可控且易于获取。Python00
kylin-wayland-compositorkylin-wayland-compositor或kylin-wlcom(以下简称kywc)是一个基于wlroots编写的wayland合成器。 目前积极开发中,并作为默认显示服务器随openKylin系统发布。 该项目使用开源协议GPL-1.0-or-later,项目中来源于其他开源项目的文件或代码片段遵守原开源协议要求。C01
PaddleOCR-VLPaddleOCR-VL 是一款顶尖且资源高效的文档解析专用模型。其核心组件为 PaddleOCR-VL-0.9B,这是一款精简却功能强大的视觉语言模型(VLM)。该模型融合了 NaViT 风格的动态分辨率视觉编码器与 ERNIE-4.5-0.3B 语言模型,可实现精准的元素识别。Python00
GLM-4.7GLM-4.7上线并开源。新版本面向Coding场景强化了编码能力、长程任务规划与工具协同,并在多项主流公开基准测试中取得开源模型中的领先表现。 目前,GLM-4.7已通过BigModel.cn提供API,并在z.ai全栈开发模式中上线Skills模块,支持多模态任务的统一规划与协作。Jinja00
agent-studioopenJiuwen agent-studio提供零码、低码可视化开发和工作流编排,模型、知识库、插件等各资源管理能力TSX0126
Spark-Formalizer-X1-7BSpark-Formalizer 是由科大讯飞团队开发的专用大型语言模型,专注于数学自动形式化任务。该模型擅长将自然语言数学问题转化为精确的 Lean4 形式化语句,在形式化语句生成方面达到了业界领先水平。Python00