加载失败
这篇文章来自 Chapel（一个面向并行/HPC 的编程语言）团队的博客，讨论“30 年来 HPC 硬件进步很大，但新编程语言几乎没被广泛采用”这个问题。评论默认的背景是 HPC（高性能计算）里长期占主导的 Fortran、C、C++、MPI、OpenMP 和 CUDA 生态，以及围绕 cluster、batch scheduler、memory bandwidth、locality 和 RDMA 的调优文化。文中和评论里还多次提到 Chapel 与 LLVM（一个编译器基础设施）的关系，以及它常被放在 HPE Cray EX/XC（HPE 的高性能计算系统）这类机器语境中衡量。争论的核心并不只是“语言是否现代”，而是新语言能否在不牺牲性能、可复现性和现有工具链的前提下，真正表达通信、局部性、加速器和作业调度这些 HPC 现实问题。
不少评论认为，HPC 里真正卡住性能的往往不是语言不够新，而是 memory bandwidth 和数据布局。很多代码看起来甚至“单线程”反而更快，因为它们已经在尽量减少 cache miss、拷贝和无谓同步。评论里反复提到 `__restrict`、prefetch、`assume_aligned`、cache 调优这些手段，说明 C/C++/Fortran 这套老工具已经足够贴近硬件。按这种看法，新语言大多是在解决并不紧急的问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
另一派认为，文章低估了分布式通信、latency hiding 和 accelerator 编程的难度。真正麻烦的不只是单机内存带宽，而是跨节点的 message passing、RDMA、kernel fusion、memory tiling，以及如何把状态映射到整台机器上。有人强调 GPU、FPGA、ASIC、ARM 等平台让硬件目标越来越碎，C++/MPI 只能覆盖其中一部分。这个视角下，问题不是“要不要新语言”，而是“要不要更高层但仍可调优的抽象”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论里对 Rust、Julia、Chapel、Mojo 都有讨论，但没人把它们看成完整答案。Rust 被认为安全性更强，`&mut` 近似于被编译器检查过的 `restrict`，但 ergonomics、复制倾向、stable allocator 和 nightly/unsafe 依赖都被吐槽。Julia 被说接近 C++ 性能，却仍难做到完全避免多余读写；Chapel 被认为有价值但不一定比现有并行接口更高明；Mojo 则更像面向 tensor graph 和 accelerators 的特定方案，而不是通用 HPC 语言。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
很多人把 adoption 缓慢归因于生态和人才，而不是语法本身。C++、Fortran 和相关库已经积累了大量长期代码、框架和领域知识，比如 Trilinos、Dakota 这类库会把通用能力直接塞进现有生态，而不是另起炉灶。HPC 开发还需要 batch scheduler、parallel file systems、NUMA、Infiniband 和具体学科知识，招聘和留人本来就难。评论还指出，Chapel 这类新语言常被拿来做“没被广泛采用”的反例，本身就带有价值判断。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
不少人说，真实的 HPC 日常并不像想象中那样全是手写 C++ kernel，反而经常是 Python、R、Perl、awk 和 workflow manager。生物信息学被视为一个明显的例外或变体：它更偏字符串处理和批量任务组织，很多问题根本不需要传统意义上的超级计算。于是大家更在意如何把任务流、数据流和并行拆分自动化，而不是换一门更“高级”的编程语言。对很多用户来说，他们需要的是 high-throughput computing，而不是纯粹追求峰值 FLOPS 的 HPC。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
也有人为模块系统、Slurm 和容器化之外的老办法辩护，认为它们虽然丑，但符合 HPC 的现实需求。environment modules 能把编译器、MPI、库版本显式记录下来，方便几年后复现论文；Slurm 也仍然是大规模调度、cgroup 绑定和 accelerator 亲和性的实用方案。批评者觉得这些工具像 pre-systemd 时代的遗留物，甚至与脆弱的集群运维绑在一起，但支持者认为问题更多在于 cluster 管理差，而不是这些工具本身。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
memory bandwidth: CPU/GPU 与内存之间单位时间能搬运的数据量，常是 HPC 的核心瓶颈。
MPI: Message Passing Interface，分布式内存并行程序最常见的通信标准。
OpenMP: 用于共享内存多线程并行的编程接口，常见于 C/C++/Fortran。
Slurm: HPC 集群里常用的 batch job 调度器，负责排队、分配资源和启动作业。
RDMA: Remote Direct Memory Access，网络设备可绕过 CPU 直接读写内存，减少通信延迟。
CUDA: NVIDIA 的 GPU 编程平台与生态，常用于写加速器 kernel。
Chapel: 一种面向并行/HPC 的编程语言，强调更高层的并行抽象。