多平台行为不一致

Creator 3.x
#22

不用浪费时间 直接选确定性物理引擎Rapier 弯路我已经走完了相信我
这是跑通的游戏: 竞速类物理引擎帧同步实现方案 - Creator 3.x - Cocos中文社区

#23

通过node --wasm-jitless xxx.js，可以快速测试得出结论WebAssembly.instantiate是可用的，只是没有了jit
那么，其实是否可以考虑将Cocos中的–jitless换成–wasm-jitless呢？

#24

你电脑上应该安装的nodejs版本很高，高版本的node自然也带了v8的最新drumbrake

理论可行，但目前V8构建iOS的静态库，构建配置启用 v8_enable_drumbrake 会报错

image
image722×118 13.1 KB

#25

所以我理解是其实关闭v8_enable_drumbrake的情况下构建，
打开–wasm-jitless也只是能保证有WebAssembly模块可以使用，
对性能没有任何帮助？

#26

开启wasm不会提升解释器环境的js性能，两者独立，增加v8_enable_drumbrake是为了保证iOS环境也能用wasm，做到跟android一致。合理使用，wasm的性能都比js要强

#27

我想wasm环境支持应该是V8_ENABLE_WEBASSEMBLY控制？
但Cocos使用–jitless导致wasm丢失支持（node.js使用–jitless也会导致wasm无法使用）？
所以收敛为–wasm-jitless更小范围以保证ios审核问题同时可执行wasm，不考虑执行性能问题？

#28

image

寄
翻到v8里的一条说明，不用纠结了

#29

这并不绝对

v8不是有wasm吗？

  • v8自带了wasm，其在jit模式下满血性能释放，在非jit模式下，v8其实也有一个非jit模式wasm，用于v8内部测试等研究，其性能很差且维护也很烂（出于维护成本考虑，可能v8在非jit模式就不想开放wasm），你截图的内容应该是指Google v8团队研发的的非jit模式wasm的补充说明。

为什么叫drumbrake？

  • drumbrake是微软技术团队贡献的一个解释器模式wasm，因Edge转向Chromium内核后，微软一直在深度参与Chromium和v8的迭代维护，贡献了非常多的能力，drumbrake是其中代表性的一个产物。微软也把drumbrake提交到了v8仓库，v8团队也做了合并。

drumbrake特点是什么

  • 和v8深度绑定，不支持其他js引擎
  • 解释器模式运行
  • 64位only

v8为什么不将drumbrake变成非jit模式下的正式wasm？

  • 我猜测政治因素多一点（脸面问题），自行体会把