为什么使用多线程执行数组比对任务反而比单线程运行速度更慢？

1. 任务类型为内存密集型，瓶颈不在CPU核心数 #

你当前的任务核心操作是memcmp两个1KB的数组，几乎没有计算量，性能瓶颈完全取决于内存访问带宽，而非CPU核心算力。
M1 8GB版本的统一内存带宽约为68GB/s，单线程跑满memcmp时已经占用了相当比例的带宽，多线程同时发起内存读取请求时，会直接打满内存带宽，新增线程只会增加调度开销、引发内存访问排队，不会带来性能提升，甚至会出现耗时上涨的情况。
你提到的7个可用核心是GPU核心，当前基于pthread的代码完全运行在CPU上，GPU核心没有参与运算，也不会带来算力加成。

2. 数据访问模式缓存友好性极差 #

你当前的任务拆分逻辑是按线程数作为步长跳取外层循环的i值，比如线程1取i=0、4、8...，线程2取i=1、5、9...，这会导致每个线程访问的voxelGroups[i]在内存中是不连续的，完全破坏了CPU的缓存预取机制，缓存命中率远低于单线程连续访问的场景，额外增加了大量内存访问开销。即使没有锁的开销，多线程的内存访问效率也会远低于单线程。

3. 任务拆分存在负载不均衡问题 #

外层i对应的内层j循环次数是随i增大线性减少的：i=0时需要跑321535次j循环，i=321534时只需要跑1次j循环。你当前的拆分方式会让分配到小i值的线程承担远多于其他线程的工作量，其他线程早早完成任务进入空等状态，整体资源利用率极低。

4. 锁开销（次要原因） #

你当前用全局互斥锁保护计数变量，即使匹配概率很低，也会带来额外的开销。如果匹配概率较高，锁的竞争会进一步放大性能损失。

• 调整任务拆分逻辑：按连续i段分配给不同线程，保证每个线程访问的内存连续，同时提前计算每个线程分配的i对应的总j循环数，保证负载均衡。
• 消除全局锁：每个线程使用私有计数器统计匹配数，所有线程执行完成后再汇总到全局结果，完全避免锁竞争。
• 前置哈希校验：先为每个voxelGroup计算32位/64位哈希值，比对时先比对哈希值，只有哈希值相等时再调用memcmp校验，可减少99%以上的memcmp调用，总耗时可降低到秒级。
• 适配GPU计算：该任务属于高度并行的SIMD友好任务，可通过Metal框架将计算逻辑迁移到你闲置的7核GPU上运行，能获得数量级的性能提升。

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