Goals and usecases for libm

[gnzlbg]

There are a bunch of changes being proposed and merged for libm that deal with the "architecture" and I have the feeling that everyone has a different idea of the goals of the project.

I think it would be worth it to collect all possible goals and use cases, before we start discussing which ones of them do we want to pursue, and which ones would be out-of-scope.
I've written a small document that collects the goals that came to my mind. It can be collaboratively edited, so please do add everything that comes to your mind.

Once that is done, I'll summarize it, and we can start having a meaningful discussion about which goals of that list should the project have. Once we have consensus on that, it will be easier to know on a case-by-case basis whether the changes being proposed are progress towards those goals or not, and which architecture we should have for achieving those goals.

(If necessary we could have a small 15 min meeting about the goals after the list is collected and the summary is written with stakeholders)

cc @alexcrichton @Schultzer @burrbull @m1el @rrbutani @rust-lang-nursery/libm

[alexcrichton]

As of a few months ago this was basically a dead crate and/or on life support and we needed changes for wasm. I've tried to keep it alive since then and put it on a solid foundation again by getting testing up and running. I am not personally available to lead the charge on large refactorings, major new features, etc.

That being said this is an extremely important crate now to the standard library and rust-lang/rust due to its default usage on basically all targets for some math intrinsics. This isn't a crate that should be taken lightly and pulled in whichever direction is necessary.

I don't think there's really an option right now to add as many features as possible here, but rather this crate needs to remain focused on being a streamlined implementation for various math functions that are commonly found in libm C libraries.

[gnzlbg]

That being said this is an extremely important crate now to the standard library and rust-lang/rust due to its default usage on basically all targets for some math intrinsics.

Can you elaborate on how the standard library uses this crate ? I don't find any references to it in rust-lang/rust .

EDIT: it's used in compiler-builtins: https://github.com/rust-lang-nursery/compiler-builtins

[jacobrosenthal]

Related is if libm should be usable across the no_std ffi barrier. Quite often you want to ffi some existing c code which needs libm, and libm needs libc, but libc is generally conflicting so you dont want to use either if possible. Its possible to manually copy paste and extern no mangle the libm function I need, but this isn't particularly maintainable. https://github.com/jacobrosenthal/cmsis-dsp-sys/blob/master/src/lib.rs#L24-L25 It would be ideal to somehow expose those functions as a crate using a feature flag maybe? another not ideal solution is maybe separately building c static lib and linking that in 2 steps, maybe related to #192 but boy would be nice to have a workflow for that.. especially in a non xargo world this seems painful. or maybe performance of this crate will never be no_std optimized and maybe I should go poke at https://github.com/NeoBirth/micromath ? Thoughts? Thanks

…

On Wed, Jul 3, 2019 at 12:53 AM gnzlbg ***@***.***> wrote: There are a bunch of changes being proposed and merged for libm that deal with the "architecture" and I have the feeling that everyone has a different idea of the goals of the project. I think it would be worth it to collect all possible goals and use cases, before we start discussing which ones of them do we want to pursue, and which ones would be out-of-scope. I've written a small document that collects the goals that came to my mind: https://paper.dropbox.com/doc/Goals-for-Rust-libm--AgOlAUNFtFswIE9Y8_BIhzgsAg-gRlnRke09h8fNcIeMGk4v It can be collaboratively edited, so please do add everything that comes to your mind. Once that is done, I'll summarize it, and we can start having a meaningful discussion about which goals of that list should the project have. Once we have consensus on that, it will be easier to know on a case-by-case basis whether the changes being proposed are progress towards those goals or not, and which architecture we should have for achieving those goals. (If necessary we could have a small 15 min meeting about the goals after the list is collected and the summary is written with stakeholders) cc @alexcrichton <https://github.com/alexcrichton> @Schultzer <https://github.com/Schultzer> @burrbull <https://github.com/burrbull> @m1el <https://github.com/m1el> @rrbutani <https://github.com/rrbutani> @rust-lang-nursery/libm — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#195>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADPI5HFLQSUBFUIHZ4AR4LP5RLJHANCNFSM4H5C6QUA> .

[alexcrichton]

@gnzlbg yes this is primarily currently exported from compiler-builtins for us in libstd

@jacobrosenthal this crate should be usable as a cdylib without any dependencies, yes, although you should be able to use this crate itself to define the interface rather than having to copy in theimplementation.

[gnzlbg]

So from your other posts I think we are pretty much all in agreement with the goals and use cases.

[alexcrichton]

Ok, in that case do you think we can close this?

[gnzlbg]

From the new comments, it seems there is disagreement about whether this should only expose a C API, or should only expose a Rust API (or somehow both, in different crates).

[burrbull]

I prefer both API with feature flag, or in different crates.

[m1el]

I'd prefer C API to be a separate crate since the primary purpose of this crate was to support math in Rust no_std code, and not in generic C-compatible languages.

C API has some wrinkles, that's why these C-incompatible interfaces were chosen.

[burrbull]

Yes, Rust in first place.

[gnzlbg]

Can anybody explain me why a Rust API is required to use this in no_std core binaries?

We currently provide a Rust API, so we need to modify the compiler-builtin crate to wrap this Rust API into a C API (e.g. see https://github.com/rust-lang-nursery/compiler-builtins/blob/9eafb677ada5c5c32873ca1c02a47feb64a87bb5/src/math.rs ), so that we can expose it via a Rust API again in libcore / libstd (Rust->C->Rust).

If we were to provide a C API on top of the result, e.g., by calling the libcore math functions, we would have a Rust API wrapped in C wrapped in Rust wrapped in C (C->Rust->C->Rust). That feels a bit nuts.

AFAICT, if this had the C API, we could just compile it, and link it, and that would "just work". LLVM emits platforms' math symbols for the libcore APIs, which if this library was linked, would be defined, and that's it. We end up with just Rust->C, which is what happens in all other platforms, and you have the benefit that if you call C code, that would just do a C->C when using the Rust math library.

AFAICT either way, everything can be inlined, but I must be missing something, since we could just expose here the extern "C" C APIs, and get the best of both worlds, while avoiding the Rust->C->Rust dance.

[Schultzer]

@alexcrichton What are the cons of adding C API? I understand that it's C`ism and old baggage that we rather not carry.

@m1el

C API has some wrinkles, that's why these C-incompatible interfaces were chosen.

Are wrinkles?, for example that in sincos you need to provide two references/pointers?