Design: 提案：Wasm 的 Fp IEEE 合规级别标志（Wasm Scalar 和 SIMD 的 FP-Fast-Math）

创建于 2021-01-12 · 7评论 · 资料来源: WebAssembly/design

gcc、clang、msvc 等原生编译器允许开发人员通过编译指示或编译时标志（如 /fp(strict-fast)、ffast-math、-ffp-contract 等）设置 fp IEEE 合规级别。一系列应用程序（例如 ML-convolutions、DSP、低精度图形/物理引擎..），其中开发人员更喜欢在便携精度方面进行权衡以换取性能。

根据使用的特定设置和编译器，性能提升可能很大。这些开发人员提示/首选项允许编译器安全地执行更多的 Fp 数学优化、更好的指令选择（融合/fma）、值范围限制和宽松的验证。

目前，当开发人员为 Wasm 指定这些标志时，开发人员工具链会使用这些标志，并且根据使用的特定工具（例如 https://github.com/WebAssembly/binaryen/pull/3155），它们可能会使用一些标志。这些首选项信息将被丢弃，如果他们希望使用它们，它们对于运行时不可用/不可见。

Wasm 运行时可以受益于访问这些开发人员标志/提示的方法，以便在安全的情况下自行决定优化和指令选择。这对于执行额外的运行时优化特别有用，尤其是在 AOT wasm 编译器中。这也有助于解决 FP Wasm SIMD 代码生成中的一些已知性能问题，如舍入、最小值/最大值等。一个高级别的，这将允许运行时不依赖于开发人员工具进行某些 FP 优化，并删除一个阻止程序Wasm 可以更密切地跟踪原生性能。

JVM 1.2 有先例将 IEEE 合规性放宽为默认模式，并引入“strictfp”修饰符以确保类/接口/方法粒度的可移植性。有机会为 Wasm 探索一种更向后兼容的方法。

我想提出一种机制来编码 Wasm 二进制文件中的 fp IEEE 合规标志，以供运行时引擎使用。与本地语言的情况一样，标志本身可以被视为可选，它们的使用可以是运行时的选择。影响将表现为性能提高、给定平台上的语义一致以及平台可移植性降低。所提出的机制将能够以指令块的粒度使用这些偏好/提示明确地标记 Wasm 二进制文件中的代码部分。

当我们继续进行时，可以详细解决该设计，一种选择是引入一个新的自定义部分，其中包含条目标记首选项和代码段偏移量，另一种选择是引入一个新指令来标记具有这些开发人员首选项的代码段，如在 JVM 中。支持的特定标志可以在我们继续进行时讨论和合并（例如 -fp-finate-math-only、-fp-no-signed-zeros ..）

该机制将补充讨论，将标量/向量FMA 和 FP 近似指令添加到 Wasm 和/或 SIMD 规范。

本期是为了追踪对这个话题的兴趣，并在CG同步中讨论这个问题。

资料来源

arunetm

👍1

最有用的评论

使用 gcc/clang 的 -ffast-math 的典型项目正在编译为本机代码。使用它们的应用程序开发人员通常会测试他们自己构建的所有本机代码变体。并且由于所有流行的硬件 ISA 都具有完全确定的浮点行为，一旦开发人员测试了这些变体，他们就可以相当确定其行为不会为他们的用户改变。目前，WebAssembly 的浮点也以这种方式工作；它是完全确定性的，就像硬件 ISA 一样，因此现有的长期存在的开发人员假设能够添加 -ffast-math 并测试它是否“适用于他们”得到支持。

WebAssembly 级别的 -ffast-math 标志意味着 WebAssembly 在这方面不再类似于硬件 ISA，并且不再支持这些假设。开发人员会测试他们生成的二进制文件，但是当将 wasm 发送给他们的用户时，他们的用户应该期望能够在不同的硬件或不同的引擎上运行它。在 WebAssembly 级别使用类似快速数学的标志，WebAssembly 的行为不会像 ISA，并且用户可以看到与开发人员测试时不同的浮点结果。

还值得指出的是，在今天编译到 WebAssembly 时，使用这些标志的项目并没有错过。例如，-fassociative-math 启用的许多优化都是 LLVM 在生成 WebAssembly 之前能够进行的面向循环的优化。

sunfishcode 于 2021-01-21

👍2

所有7条评论

由于 fp 操作的严格性会影响程序的语义，我希望使更宽松的语义成为可能的最佳方法是引入新指令而不是自定义节或块构造。由于我们的 NaN 传播规则，我们已经拥有处理浮点非确定性所需的规范机制，因此我希望引入新的浮点指令以实现更多可能的结果会很简单。

tlively 于 2021-01-12

作为附加上下文，JVM 正在考虑删除strictfp并仅支持严格语义。

sunfishcode 于 2021-01-12

👍1

使更宽松的语义成为可能的最佳方法是引入新指令而不是自定义部分或块结构。

引入新指令是有用的，但它不会很好地扩展或完全删除工具链依赖。具有良好平台支持的指令，如 fma、reciprocal 等，是添加新指令的良好候选者。本机编译器提供的提示/标志种类繁多。
-fassociative-math -ffast-math -fno-honor-nans -ffinate-math-only -fdenormal-fp-math -fno-strict-float-cast-overflow -fno-math-errno -fno-trapping-math ...
其中大部分是允许更积极的 fp 优化解除对代数转换、nans、有符号零、陷阱、舍入等限制的提示。将所有有用的标志表示为新指令并不是理想的 imo。

作为附加上下文，JVM 正在考虑删除 strictfp 并仅支持严格语义。

感谢@sunfishcode添加的上下文！我不知道这个新更新，似乎动机是整合数学库变体。仔细观察，Java strict-fp 似乎更专业一些，并且不能很好地表示 gcc/clang 提供的控制点范围。 -ffast-math 标志和相关标志在 github 的快速搜索中似乎在本机 repos 中非常流行。我计划研究上述标志和相关参数的用途

arunetm 于 2021-01-12

sunfishcode 于 2021-01-21

👍2

是的，任何影响浮点精度/行为的决策都应该由工具烘焙到 Wasm 模块中。可以为无法用当前指令表达的行为添加新指令。

aardappel 于 2021-01-21

我们在上次 CG 会议上讨论了这个主题，将新指令添加作为目标的替代方法。似乎普遍有兴趣通过后一个方向解决这个问题。如果开发人员对性能提升的期望可以通过工具链优化和引入缺失的指令变体来维持，我不反对。在这种情况下，没有必要证明将这些标志传播到运行时会损害 Wasm 的抽象级别。了解实现此目标所需的语义变体指令将是一件好事。我们在 SIMD 的上下文中确定了一些新指令，可能需要对其进行扩展以匹配指令工具需要完全表达快速数学标志。将继续朝那个方向看。

感谢您的反馈。

arunetm 于 2021-01-22

用于 CG 讨论的内容。 Wasm ffast-math.pptx

arunetm 于 2021-03-01

此页面是否有帮助？

0 / 5 - 0 等级

Design: 提案：Wasm 的 Fp IEEE 合规级别标志（Wasm Scalar 和 SIMD 的 FP-Fast-Math）

最有用的评论

所有7条评论

相关问题