-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Pull float support into separate libmath #2198
Comments
As a side node, this should make it easier for users to switch the used implementation of C libmath by using a different rust math crate. This may happen in numeric computing where lib math can be optimized for different goals (throughput, precision, latency). |
In what sense does it cost an individual program to have more functions in std/core? I mean, if it's dynamically linked, then the libs are installed anyhow. If it's statically linked, stuff you don't use gets stripped out, doesn't it? Or is my understanding of linking incomplete or overly idealized (entirely possible)? Regarding "virtualizing" the math library in use, that makes sense, I guess it can be emulated in any case by having your program define a |
Regarding linking: Did not think about stripping in the static case. In the dynamic case, a program that doesn't deal with floats would not have to link against C lib math at all, so there would be a minimal benefit. It would also make testing libmath a bit easier, as it would not require a full build of std :) Regarding virtualization: If core is linked against lib math, you have to carry it around even you don't use it. Here my understanding of linking is perhaps insufficient but I think it causes problems to link against two shared libraries that have the same symbols (lib math via core and actually used lib math)? |
I did this to try it out, see src/libmath in |
All is coming along nicely, I could use some help with setting up the build of lib math properly https://github.com/boggle/rust/commits/libmath Left todo: (1) Fix building (running tests breaks) (2) Get a snapshot with lib math (3) Move tests from core to lib math (4) Retarget core, std against lib math except for to,from_str (5) kill old math core from core after another round of snapshotting |
@boggle Have you been able to get the help you were looking for? |
kind-of, was talking to brson on IRC the other day but did not have time this week to hack things further. There is a unresolved dependency issue, I'd like to have core /not/ depend on math but this requires some code duplication and I have to dig deeper to see if this is possible. If not, things are plain and core just reexports the new math lib. |
@boggle What is blocking you? |
I did some work on a branch to remove the core dependency from libmath but hit some bugs in the snapshot compiler when building core. |
not going to grow to the size of libGSL or something, Im happy closing this WONTFIX and keeping math in core. Any objections? |
@graydon: no objection from me, I think letting the compiler worry about it with LTO is to the solution to this type of problem :P |
We've migrated a lot towards using LLVM intrinsics and our own implementations of the simple functions, so I think this is no longer really an option. We could avoid the usage of the system's |
Refactor POSIX to UNIX This renames the directories containing posix to unix; where applicable, it also rename functions with the word "posix" to "unix" Fixes rust-lang/miri#2012
Some contributors are already following this guide regarding diagnostic output style, but this isn't mentioned anywhere. This PR is more of a proposal to officially adopt these style guidelines. It adds a sentence noting this and linking to the guide itself.
I start to get the feeling that the float parts of core are too huge to have them linked into every rust program. Besides, #2187 suggests an overhaul of math. So is it time to pull it into a separate lib, just like in C, and only keep as few as possible but required minimal bits in core?
The text was updated successfully, but these errors were encountered: