请教一个 CPU 密集计算多线程优化办法？

[James369]

我在写一个 js 前端项目的时候，遇到一个比较耗时的操作 task，它基本结构是一个 2 层的 for 循环计算，task 大体长这样：

function task(x: Int) {
  ... 
  for(var i = 1...10000) {
    for(var j = 1...10000) {
      ...计算数据（与参数 x 相关）
    }
  }
  ...
}

这个 task 在点击按钮时触发，要耗时大概 3 秒左右，为了不阻塞 UI 界面。我想开子线程去优化。那么开子线程能否做到以下几点：

1. 不管用户如何快速的点击按钮，这个 task 子线程始终保持在 1 ～ 2 个（避免开启过多线程）
2. 当用户点击按钮时，如果已有 task 未执行完毕，可以先终止或跳出原 task，再执行新 task 。
3. 假如在开启子线程执行 task 时，需要再传入一个大的 Object （例如 task(x: Int, big: Object)），那么这个 Object 要不要做多线程同步，如何做？

第 3 点如果做不到，那就放弃第 3 点。

[mxT52CRuqR6o5]

@secondwtq
我的论点重点在于解决 js 性能问题时，相比 fiber 、webworker 、gpu.js 相比，wasm 考虑优先级要低
你搁这使劲跟我掰扯“一个级别”“基本不用”的用词含义我也不知道是几个意思

[secondwtq]

@mxT52CRuqR6o5

> 起码 5 倍差距以上吧，不然 O(n)和 O(2n)都不算一个级别了
你都加 大 O 了常数项还有意义么 ...

> “一个级别”“基本不用”的用词含义我也不知道是几个意思

我的意思是
1. “因为后端一样，所以性能一样（或者一个级别）”的逻辑是错的
2.
> 相比 fiber 、webworker 、gpu.js 相比，wasm 考虑优先级要低
这个比“基本不用”看上去合理一些，我也觉得 WASM 一般相对于这些不是很合适。
但是我不觉得到了“基本不用”的程度。

> 底层的东西性能提升几个百分点是很有价值的，但业务层的东西就不是了

所以
3. 那也要看什么业务啊。你直接说
> 相比 fiber 、webworker 、gpu.js 相比，wasm 考虑优先级要低
不就得了，为啥非要直接一个“基本不用”扣上以至于引起
> 纯属抠字眼
> 用词含义
的误会呢。

[secondwtq]

***本回复不是给 #28 #30 #33 #34 #36 #37 #40 #41 看的，而是给通过 V 站站内通知、Google 等不同渠道来的有缘人看的***

不是刻意要“抠字眼”，解释下我为啥以 2 作为普遍的“级别”的粗略定义：

考虑工资 6k 和工资 8k 的两个人，可以勉强说这两个人的工资是一个级别。工资 6k 和工资 60k 就明显不是了。10 是一般意义上的“数量级”单位。但是在很多情况下这个单位都太大了。工资 12k 相对于工资 6k，已经是“一个级别”的边缘了。同样的规律可以应用在价格上。
孙子兵法更有意思“十则围之，五则攻之，倍则分之，敌则能战之，少则能逃之，不若则能避之”，，看起来其对于军队数量级差距的定义在 2-5 倍之间，而 10x 在这套标准中已经是顶级的碾压了。
2 对于程序员来说是比较习惯的选择，我认为也是比较合适的选择。某些时候可能显得有点小，不过无非就是原来的一个数量级变成了现在的 3.3 个数量级。
意大利有 60M 人口，尼德兰有 17M，这俩也就 3.5 倍的关系，但无论如何不能说是在一个级别上。
我现在用的显示器是 2560 × 1440 的分辨率，相对于 1920 × 1080 的屏幕是 1.78 倍像素点，而 1920 × 1080 相对于 1280 × 720 是 2.25 倍的像素点，两个比率都在 2 倍“左右”。实际用过的大概知道，这三种分辨率用起来完全不是一个级别的体验。
一般做性能优化，除去明显的低级错误后，各种 trick 提升的天花板也就是 2x，再往上就要靠并行和程序本身算法优化。但是不考虑实现方式和 KPI 好不好看，作为用户来讲，大量数据占用存储减半，复杂页面加载时间减半，能耗减半，模拟迭代速度速度翻倍，多媒体处理或游戏帧数翻倍，数据传输速率翻倍，这些都是能明显感觉到的东西——实际上对于很多比较成熟的系统做到这些都非常不容易，但是如果做到了，使用体验是超出一个级别的提升。所以我对性能问题的“数量级”定义是低于 2x 的。