这是一个创建于 812 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
gimp 2022-09-28 10:01:53 +08:00
不清楚，要不提个 Issus 问问
|
 |
2
inhzus 2022-09-28 10:23:09 +08:00
v8 牛逼？
|
 |
3
warcraft1236 2022-09-28 10:29:33 +08:00
是不是没用到相应的指令集
|
 |
4
xiangyuecn 2022-09-28 10:51:32 +08:00
现代浏览器 buffer 加持：
Array.from(new Uint8Array( await crypto.subtle.digest('SHA-1', new Uint8Array(unescape(encodeURIComponent("牛逼")).split("").map(b=>b.charCodeAt(0)))) )).map(b=>('0'+b.toString(16)).substr(-2)).join('') |
|
5
xiangyuecn 2022-09-28 10:55:25 +08:00
搞错了，AES 是用 crypto.subtle.encrypt 😂 支持 AES-CTR 、AES-CBC 、AES-GCM
|
 |
6
liuidetmks OP @warcraft1236 应该都是纯软件实现吧
|
 |
7
Wincer 2022-09-28 14:11:38 +08:00  1
从对比图里我没看出来 wasm 慢了，明明 wasm 的计算时间比 js 要短，怎么就变成慢了？
|
 |
10
Al0rid4l 2022-09-28 17:49:44 +08:00
总是有人以为 JS 很慢...其实 JS 基本上算是脚本(或者解释型, 按照大部分人的定义来说)里面最快的了
不过这种对比吧, 你也不知道他具体实现是怎样的, 也许双方抠抠细节都还能有较大提升 |
 |
11
tool2d 2022-09-28 18:00:30 +08:00
官方制图是不是搞错了，我用 github 上的测评页面运行了一下，wasm 明显比 js 快了很多。
 |
 |
13
systemcall 2022-09-28 23:20:44 +08:00
@inhzus #2
FireFox 和 V8 有什么关系？ |
 |
14
sutra 2022-09-29 19:30:27 +08:00 via iPhone
这图不是循环 10 次，wasm 用时更短的意思？
|
 |
15
param 2022-09-30 03:49:55 +08:00 via Android
我这后者快点，手机上跑的
|
 |
16
PeterAlfredLee 2022-09-30 09:05:32 +08:00 1
想不到看到了在 V2EX 上看到了自己的东西 :)
这个 benchmark 出来结果后，我们也内部讨论过(甚至对 aes 有针对性优化，但是效果不明显)，跟大家的看法差不多： 1 、js+V8 没那么拉垮，JIT 应该还是很明显的 2 、aes 的计算量不大(从运行时间也能看的出来)，在这种情况下，wasm 由于内存拷贝(胶水代码所负责)所附带的性能影响较明显 由于相关调试工具的缺失，这块没有深究下去，大家有兴趣也可以讨论下 另外，在测试中还发现了一些有意思的地方：chrome 在开启 performance record 后，性能表现较好，结果也比较稳定，猜测是 chrome 在 performance record 时会对内存及时进行清理。 @tool2d @des 我们的 benchmark 是有 warm-up 的，已经考虑了 jit 等优化，benchmark 代码开源在 github ；列出的测试结果是在一般的硬件条件下获得的，大家硬件不同，不过一般来说都会比我们所列的测试结果要好 最后，虽然有点王婆卖瓜的不好意思，但是还是介绍一下 crypto-js-wasm：相比于原来的 crypto-js ，除了引入 wasm 外，还用 ES 进行了重写、加入了 rollup 打包和 jest 测试，还增加了 ts 的支持。后续还考虑增加更多算法(对标 openssl)、加入 simd 、适配其他 runtime(比如 RN) 希望大家可以尝试用用 crypto-js-wasm ，当然 issue 、pr 就更欢迎了 |
Select Language