(Pre)Proposal: wasi-math

[oovm]

I would like to make some comments here: Is it necessary to develop wasi-math?

---

Motivation

Many people want to use some slightly complex mathematical functions in wasm, but their high-performance implementation is actually not simple, especially in wasm.

• https://github.com/WebAssembly/design/issues/1503
• https://github.com/WebAssembly/wasi-libc/issues/92

So I'm wondering if it's possible to add math functions to the next stage of wasi (in preview3)?

In this case, the host platform can directly use hardware acceleration on platforms that contain corresponding instructions, and use programming implementation on platforms that do not support it.

---

Goals(MVP)

The initial goal is to achieve the same computing power as Javascript Math.

Including abilities such as large integers, trigonometric functions, inverse trigonometric functions, exponential logarithms, etc.

Non-Goals

• Already included in WASM
  • min, max
• The algorithm is extremely simple
  • Fibonacci Sequence, 3n+1
• Difficult to implement the optimal algorithm
  • Prime number, determine whether it is a prime number

To be discussed

• The number theory function is a very commonly used function in cryptography.
  • I don’t know what component it should belong to.
  • Mathematics? Cryptography? Or a dedicated number theory proposal?
• Vector operations, quaternions
  • is very common in games, and I focused on the needs of platforms such as Unity.

[sunfishcode]

It is possible to add math functions to WASI. It's even possible to add them to Preview 2. I expect the main challenge is to find a clear scope that can be sufficiently motivated.

General-purpose CPUs today typically don't have hardware acceleration for trig/exp/log/etc. functions. x86 does have sin/cos/tan instructions, however it turns out that they're slower than just computing those functions in software. Consequently, the apparent advantage here is just toolchain convenience.

There are decently high-quality open-source implementations of things like trigonometric and exp/log/pow functions available. It is less convenient for toolchains to integrate them, however many toolchains today are able to do this. And in return, there are significant advantages to having toolchains do this.

Today's JavaScript engines typically don't implement correct rounding (and indeed, are not required by the spec to do so), so results will often differ in the last digit or so. And, the performance can vary significantly between platforms. Having toolchains bundle their own implementations avoids both of these problems.

And, for some applications, today's JavaScript engines' trig functions compute to a level of precision that is greater than needed, and as a result are slower than they'd need to be. Having toolchains provide their own algorithms gives them the ability to make their own speed/precision tradeoffs, and in a way that's deterministic for a compiled Wasm. And it doesn't require Wasm or WASI to include a specification for reduced-precision math, which can be pretty tricky. Naive attempts can break important symmetries like cos(-x) = cos(x) or invariants like sin(x) <= 1, and different use cases need different things (for example, some applications care about sin(x) for really big values of x, while others don't).

In summary, what's needed here is for someone to propose a specific scope for what should be included, what the precision and determinism requirements should look like, and what the performance expectations should be.

[oovm]

Regarding the balance between accuracy and speed, many languages have a mode called fast-math, which guarantees accuracy by default and speed in fast mode.

The following options are available:

Keep both

Just like wasi:random has both a safe but slower version and a fast but unsafe version, it is possible to have both math and fast-math interfaces at the same time

Shortcoming

There is only one correct answer, but there are many approximate answers, each with different trade-offs and application scenarios. In fact, there may not be a fast-math version that can satisfy all users.

Moreover, fast-math does not have various strict IEEE standards, and there may be differences in various programming languages.

Fallback Mechanism

• https://github.com/WebAssembly/component-model/issues/310

We don’t know yet how this mechanism will work, and it may add unnecessary complexity.

Only keep high-precision version

Practical factors

Although the accuracy provided by js is already excessive in most cases, when considering applications such as physical simulation (such as three-body motion simulation demo), a high-precision correct version is still needed.

Size factor

Compared with the fast, accuracy-sacrifice version, the correct, high-precision algorithm will require a lot more binary code.

So I think letting the host bear this cost is a better trade-off.

If users need fast-math, they can choose the appropriate version in each language and according to their own ecology.