并行编程语言其实是个笑话⋯⋯

Programming
,
1

我几年前用 Chapel 写了 GitHub - LdBeth/riemersmadither: Riemersma Dither ，因为当时还不会写 C，没比较过，盲目信了用上并行性能会更强的说法。

结果今天让 gpt o3-mini-high 重写成 C 了，性能提升了 10x 有余，还都是 LLVM 做的后端差别能有这么大。

/Users/ldbeth $ time { /Users/ldbeth/Public/Projects/riemersmadither/rdc  a.ppm m.ppm g.ppm }
465.216ms
/Users/ldbeth $ time { /Users/ldbeth/Public/Projects/arc/ppmriemer --ifile=a.ppm --pfile=m.ppm --ofile=k.ppm }
38.907173417s
/Users/ldbeth $ file a.ppm 
a.ppm: Netpbm image data, size = 2735 x 4096, rawbits, pixmap

原因显然是因为 Clang 的自动向量化做得比 Chapel 强多了。Chapel 把精力都放在 GPU 支持上结果在纯 CPU 计算上显然被 C 吊打。

4 个赞
2

在做并行的时候，如果是CPU平台，常见方案是直接用MPI+OpenMP，GPU平台的话是用MPI配合CUDA。在高性能计算的论文里一般都选的是这种技术栈，并行编程语言好像还真没看到有人用过。

1 个赞
4

GitHub - arrayfire/arrayfire: ArrayFire: a general purpose GPU library. 这种封装都不常见？

5

我还真没见过这个库（

可能是领域不太一样，我自己和身边做传统科学计算的人里，都是只针对特定平台优化的，调库基本都是直接调BLAS或者FFT库，不太注重移值性，不怎么依赖这种封装好的库。做AI模型加速的人里，有Libtorch或者Tensorflow就已经足够了，也不会再引太多的额外封装库。

6

上学期学了下并行编程，全是科学计算，的确是就这三样，加一些并行计算的理论，没有提到过任何并行编程语言

7

自动向量化是 LLVM 的工作，不是 Clang 的。当然想要 work 得好的话对前端可能有一定要求，不过 Chapel 如果提供了对向量化的支持，这些基本的事情应该是做了的。

楼主的工作，缺了性能分析这一步。

哦对了，其实我觉得 CUDA 和 OpenMP 某种程度上也算是“并行编程语言” …

8

提供了如提，文档里这样写的，

If the --vectorize compiler flag is thrown (implied by --fast), the Chapel compiler will emit vectorization hints to the backend compiler, though the effects will vary based on the target compiler.

反汇编一看在 ARM64 上连 neon 都没用上，x86_64 也没看到用 xmm ymm (如果仔細看，还是有一点的，但明显不如 C 编译出来的用的多)，实际上做并行化就是把 forall loop 编译成多线程，看着是把 CPU 十多个核跑满了，结果原来还不如单线程 SIMD。

显然是 chapel 生成的 IR 不滿足 llvm auto vectorization 的要求。都这样了，还有啥性能好分析的，结论就是 chapel 的 vectorization 好几年了还是只存在于 ppt 上。

我黑的就是那些卖点是所谓编译到 CUDA，OpenMP 的，用 LLVM 当后端的并行编程语言，实际上没有任何性能优势，没了后面的 API 纯 CPU 一比遮羞布就给扯了，就算是用上了 CUDA, OMP，实际用上了几成也难说。