让我们一步步拆解你遇到的两个核心问题，结合GPU架构特性和你的代码细节来分析：

一、为什么“单次写入”看似导致性能暴跌？ #

首先要纠正一个容易被忽略的误区：你提到注释掉f[gID] = val;后耗时从3.5s骤降到0.05s，这不是因为写入本身慢到离谱，而是编译器的优化在“作祟”——当你去掉写入语句后，编译器会发现val变量没有被任何后续代码使用，直接把整个循环计算逻辑都优化掉了！0.05s其实只是内核启动、线程初始化的基础开销，根本没执行你写的那8192次循环。

当然，GPU全局内存的写入确实通常比读取延迟更高，背后的架构原因有这些：

• 缓存策略差异：GPU的L1/L2缓存对读取优化更充分，支持预取、合并访问和缓存命中复用；而写入一般采用写回策略，需要等待缓存行刷到全局内存，尤其是当写入地址没有空间局部性时，无法合并成高效的内存事务，会产生大量零散请求，延迟飙升。
• SIMT架构约束：GPU线程束（Warp）内的线程要同步执行，如果线程束内的写入地址不连续、未对齐，会被拆分成多个独立的内存事务，开销叠加后延迟会非常明显。

回到你的原内核，真正的性能瓶颈其实是O(n²)的全局内存随机读取：每个线程要循环读取整个p数组（8192次），这些读取完全随机，缓存命中率几乎为0，每一次读取都要触发一次慢得离谱的全局内存事务——这才是3.5s耗时的主要来源，写入只是最后一步，被编译器优化的测试结果误导了你。

二、为什么共享内存优化没带来显著提升？ #

你的第二个内核尝试用共享内存优化，但存在几个关键问题，导致共享内存的优势完全没发挥出来：

1. 算法逻辑错误，没覆盖所有计算需求
   原算法要求每个线程和p数组的所有n个元素计算，但你的优化代码只分块读取了部分工作组的数据，甚至还加了if( idx >= n) idx -= n;的取模操作，这会导致部分元素被重复计算、部分元素完全没被访问，不仅结果错误，也没真正减少全局内存的读取次数。

2. 共享内存的使用违背了数据局部性原则
   共享内存的核心优势是线程间的数据复用：多个线程需要访问同一批数据时，先把数据加载到共享内存，再由线程多次复用。但你的原算法中，每个线程需要访问整个p数组，每个数据只会被一个线程读取一次（除了p[gID]），根本没有线程间的复用场景，共享内存自然无法减少全局内存的总读取量，性能提升也就无从谈起。

3. 错误的写入时机，额外增加了写入开销
   你把f[gID] = val;放在了block循环内部，这意味着每个线程会写入get_global_size(0)/get_local_size(0)次，而非原内核的1次，这会大幅增加全局内存的写入事务数量，进一步拖慢性能。

针对你的场景的优化建议 #

• 先验证编译器优化的真实影响：如果要测试计算部分的耗时，注释写入语句后，给val加一个无用的输出（比如printf("%f", val.x);），强制编译器保留计算逻辑，这样才能得到真实的计算耗时。
• 重构算法，降低全局内存访问量：O(n²)的算法对于n=8192来说，光是计算量就有6700万次，再加上随机内存访问，GPU也扛不住。可以考虑转成具有更好数据局部性的形式，比如用分块思想，让每个工作组处理一块数据，实现数据复用。
• 正确使用共享内存：如果要用共享内存，一定要确保同一工作组内的线程会复用共享内存中的数据。比如把p数组分成多个块，每个工作组加载一块到共享内存，然后每个线程和这块内的所有元素计算，再处理下一块——这样每个块的全局内存读取只做一次，被工作组内所有线程复用，才能真正降低内存开销。

内容的提问来源于stack exchange，提问作者user1589759