Add bindings for short math vector libraries

[gnzlbg]

LLVM is very far off from properly supporting short-vector floating point math, which basically means that all/most vector math functions get scalarized.

A plan to work around could be:

• creates to interface with the platform's vector math library:

  • libmvec-sys for libm,
  • svml-sys for svml,
  • etc.

  These crates would be optional features of packed_simd, and each of them would have their own features that users could configure. Hopefully, these crates already exist, but if they don't we'll have to create them. They should not live in packed_simd, they should be their own independent crates since these are generally useful.

• use compile-time feature detection in packed_simd to manually call the implementations in those libraries when available.

[andy-thomason]

If it would help, it would be possible to implement the standard math functions cos, exp etc. in pure rust given the set of primitives available in packed_simd. This would be portable across all vector types. I have done this in C++ for many a project and would be happy to contribute.

[gnzlbg]

It should be possible to do this in a library on top packed_simd, so I think that would be a good place to start. Once we have that, we can then resolve how to expose those from packed_simd itself.

[burrbull]

@andy-thomason Have you looked at sleef-rs. I don't have time to work on it now. But I can give you access if you want.

[gnzlbg]

FWIW something like re-implementing sleef in Rust on top of packed_simd is what I had in mind as well.

[burrbull]

Or maybe it make sense to reorganize this repository. To split it on several crates in one cargo workspace. One of them can be sleef.

[gnzlbg]

Sure. The way I envisioned it was having a packed_simd_core crate that provides the basic functionality (e.g. what libcore would provide), and then have a packed_simd_floats crate that provides a trait (e.g. FloatMath or similar) with trait methods like sin, etc. and implements it for the floating-point vectors. Different implementations could be chosen depending on a cargo feature, so one could be libmvec, other could be the sleef C library, SVML, etc. A different implementation could be a pure rust math vector library, that could live here in this repo as well, and depend on packed_simd_core.

This would allow us to expose packed_simd_core from libcore before nailing the float stuff. Also, since the float stuff needs to be able to call a C library, it isn't that bad that those trait methods can't be const fn right now, but at some point it would be nice if they were (this would benefit from a pure rust vector math library as well since that could be used at compile-time, and whatever C library is chosen could be used at run-time, and the const fns could switch between these).

When including packed_simd_float into libstd, it would be something part of a libfloat that lives on top of libcore like explained here (https://internals.rust-lang.org/t/problems-with-floats/10962). Then we can have compiler options to choose the math library that's get used, and add some more magic to allow LLVM optimizations on vector math, e.g., lowering everything to llvm. math intrinsics first, and before code gen, replacing those with calls to the chosen vector library, e.g., using our own LLVM pass for it. I'd suppose Intel would be interested at some point in allowing Rust to use the SVML for customers that pay for it, so we need something like this anyways for handling normal float math as well (cc @joshtriplett ).

[andy-thomason]

That sounds eminently reasonable. I see that there are already hooks to Sleef in the library, for example. It would take a while to exceed the performance and quality characteristics of Sleef and SVML and so the choice should exist for the user. Using generic LLVM intrinsics is a good goal, although we may need to fix a few LLVM bugs and the NAN semantics are quite frankly bizarre - I site llvm.minnum as an example with optional NAN propagation requiring a 3 instruction expansion when lowering to x86. It is a shame that expansions of llvm math intrinsics often lower to library calls. Coming from the game industry, I know that advanced users expect multi-precision results from 12 bit approximations to full edge-case handling versions such as those in libm. There is a two to three order of magnitude performance difference between a libm call and a good vector implementation with the call overhead alone larger than the execution time of the optimal one. There are also design choices about throughput vs latency, register pressure and loop invariant code motion. I would appreciate help about rust issues as I am relatively new to the language but I do have some now fairly out of date experience with LLVM.

…

On Fri, Oct 11, 2019 at 10:23 AM gnzlbg ***@***.***> wrote: Sure. The way I envisioned it was having a packed_simd_core crate that provides the basic functionality (e.g. what libcore would provide), and then have a packed_simd_floats crate that provides a trait (e.g. FloatMath or similar) with trait methods like sin, etc. and implements it for the floating-point vectors. Different implementations could be chosen depending on a cargo feature, so one could be libmvec, other could be the sleef C library, SVML, etc. A different implementation could be a pure rust math vector library, that could live here in this repo as well, and depend on packed_simd_core. This would allow us to expose packed_simd_core from libcore before nailing the float stuff. Also, since the float stuff needs to be able to call a C library, it isn't that bad that those trait methods can't be const fn right now, but at some point it would be nice if they were. When including packed_simd_float into libstd, it would be something part of a libfloat that lives on top of libcore like explained here ( https://internals.rust-lang.org/t/problems-with-floats/10962). Then we can have compiler options to choose the math library that's get used, and add some more magic to allow LLVM optimizations on vector math, e.g., lowering everything to llvm. math intrinsics first, and before code gen, replacing those with calls to the chosen vector library, e.g., using our own LLVM pass for it. I'd suppose Intel would be interested at some point in allowing Rust to use the SVML for customers that pay for it, so we need something like this anyways for handling normal float math as well (cc @joshtriplett <https://github.com/joshtriplett> ). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL36XCJH6VVFXFEI2S6YQDQOBAYVANCNFSM4FPETSBA> .

[andy-thomason]

I've been building a BigInt based multiprecision math library to act as a reference for coefficient generation - still early days yet. I am converting my C++ polynomial functions to rust.

[andy-thomason]

I now have a BigRational based coefficient generator using Chebyshev approximation.

We could refine this in the future to do Remez approximation and ULP twiddling.

Here is a scalar version of sin for a taster. We approximate sin(x/(2.*PI))/(x/(2.*PI)) which is even (sinc) and then multiply by x/(2*PI). There are some trade-offs.

Doing f32 is a lot simpler as we can use f64 as a source of truth.

fn sin(x: f64) -> f64 {
    use std::f64::consts::PI;
    let x = x * (1. / PI / 2.);
    let x = x - x.floor();
    let x = 0.5 - x;
    let x2 = x * x;
    x * (-0.000079927764860745887754)
        .mul_add(x2, 0.001125557678025159357924)
        .mul_add(x2, -0.012029578845758842273184)
        .mul_add(x2, 0.104228684600363510903698)
        .mul_add(x2, -0.718122226592215695539778)
        .mul_add(x2, 3.819952576945569777677747)
        .mul_add(x2, -15.094642576275903778082466)
        .mul_add(x2, 42.058693944873638770332036)
        .mul_add(x2, -76.705859753060764205656596)
        .mul_add(x2, 81.605249276075042530464998)
        .mul_add(x2, -41.341702240399762047218246)
        .mul_add(x2, 6.283185307179587120174347)
}