Skip to content
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

Closed
boggle opened this issue Apr 14, 2012 · 12 comments
Closed

RFC: Pull float support into separate libmath #2198

boggle opened this issue Apr 14, 2012 · 12 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@boggle
Copy link
Contributor

boggle commented Apr 14, 2012

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?

@boggle
Copy link
Contributor Author

boggle commented Apr 14, 2012

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).

@nikomatsakis
Copy link
Contributor

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 math module at the root level and changing what that points at.

@boggle
Copy link
Contributor Author

boggle commented Apr 14, 2012

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)?

@boggle
Copy link
Contributor Author

boggle commented Apr 15, 2012

I did this to try it out, see src/libmath in

boggle@fbe857f

@boggle
Copy link
Contributor Author

boggle commented Apr 15, 2012

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

@catamorphism
Copy link
Contributor

@boggle Have you been able to get the help you were looking for?

@boggle
Copy link
Contributor Author

boggle commented Apr 20, 2012

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.

@brson
Copy link
Contributor

brson commented Apr 25, 2012

@boggle What is blocking you?

@brson
Copy link
Contributor

brson commented May 16, 2012

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.

https://github.com/brson/rust/tree/libmath

@graydon
Copy link
Contributor

graydon commented Apr 25, 2013

not going to grow to the size of libGSL or something, Im happy closing this WONTFIX and keeping math in core. Any objections?

@thestinger
Copy link
Contributor

@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

@thestinger
Copy link
Contributor

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 libm, but that would be a new proposal.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
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
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Development

No branches or pull requests

6 participants