Non-stable {f,u,i}128

jjpe · 2017-01-14T16:45:53.240Z

Hi everyone,

I’ve noticed that the 128-bit floating and integer types are currently available in nightly Rust. I’d like to use these and have no qualms per se about using nightly Rust. So my question is more about why: Why exactly are these types unstable atm? I’ve checked the tracking issue but there isn’t too much recent information on it there and it’s difficult to figure out which of those comments are out of date (can’t check everyone’s private forks, after all).

What issues specifically are holding the u128, i128 and f128 types back from stability? I’m asking because depending on the answers I might go ahead (or not) and use them in a project for work.

steveklabnik · 2017-01-14T17:08:46.050Z

jjpe:

What issues specifically are holding the u128, i128 and f128 types back from stability?

I can think of one thing: they were just added. New features must be in at least one full release before they’re eligible to be made stable.

jjpe · 2017-01-14T18:05:05.895Z

I see. I figured maybe there were known issues with them, but if they’re likely to work (and unlikely to be significantly altered, even if it’s possible because of the unstable label) then I may as well try them out. Thanks!

BTW, would the tracking issue be a good place to put the eventual experience I’ll have with especially f128 and i128? I’m talking about both good and bad experiences

leonardo · 2017-01-14T18:19:23.858Z

I think there’s no f128.

jjpe · 2017-01-14T18:22:07.947Z

Indeed, you’re correct!

I guess I just assumed it would be there side by side with u/i128.

steveklabnik · 2017-01-14T19:51:52.052Z

jjpe:

would the tracking issue be a good place to put the eventual experience I’ll have

Yes, this is true in general for any unstable feature.

steveklabnik · 2017-01-14T19:54:34.060Z

jjpe:

I guess I just assumed it would be there side by side with u/i128.

Yeah, the RFC was focused on integers. There’s no reason that we can’t do the same for floats.

est31 · 2017-01-14T20:19:06.417Z

jjpe:

What issues specifically are holding the u128, i128 and f128 types back from stability?

There are currently a couple of issues. i128 broke several non tier1-platforms with varying degrees, like NVPTX, MSP430 and powerpc.

Also, enums can’t have #[repr(u128)] yet.

I’m not sure which of those issues are needed to get fixed before stabilisation, but generally some feature always needs to ship for one full cycle in unstable or something.

jjpe:

BTW, would the tracking issue be a good place to put the eventual experience I’ll have with especially f128 and i128? I’m talking about both good and bad experiences

Yes, please test them! The more people test a new unstable feature, the better, as then more bugs can be found.

leonardo · 2017-01-14T20:29:00.570Z

est31:

Yes, please test them! The more people test a new unstable feature, the better, as then more bugs can be found.

It’s quite natural to solve some Euler Problems using those 128 bit numbers. I have used the extprim crate in past for that.

leonardo · 2017-01-15T11:28:54.717Z

Here’s one:

github.com/rust-lang/rust

Issue: Built-in u128 performance compared to extprim crate

opened by leonardo-m on 2017-01-15

This is a performance bug report.
This little program solves a problem derived from this (a ten times larger problem):
https://projecteuler.net/problem=55
The solution (this...

C-enhancement I-slow

jjpe · 2017-01-15T13:58:26.047Z

I do not expect performance to become a problem, not for at least the next year or so. Given that this will eventually be fixed I’ll still go ahead and try them out.

dhardy · 2017-01-16T08:06:12.592Z

est31:

There are currently a couple of issues. i128 broke several non tier1-platforms with varying degrees, like NVPTX, MSP430 and powerpc.

There can never be unity of hardware support when going beyond the lowest common denominator. Taking this argument to the extreme, is there any reason not to support some larger numbers, e.g. u256 and u512? These could be useful for example to represent hash values and do basic computation such as bitwise XOR.

That some “basic” operations like addition might be slow is rather besides the point; optimisation must to some extent be platform-specific anyway.

I see there is already a crate adding such types externally, though it appears only to support bit-logic operations (bitwise or, and, shift, etc.).

est31 · 2017-01-17T17:08:02.983Z

@leonardo thanks for your report, its greatly appreciated!

dhardy:

There can never be unity of hardware support when going beyond the lowest common denominator.

The problem on NVPTX/MSP430 is that compilation of any program fails due to i128 support having been added, not just if you use i128. Before stabilizing we need to find out whether to remove i128 support on those platforms, or whether to provide an “emulated” mode where i128 is compiled just like (u64, u64), or something else.

dhardy · 2017-01-20T10:56:22.835Z

Ah. I was arguing that providing emulation of such types is not a bad thing. [Assuming someone writes the emulation code. It should anyway be omitted from the binary if not used.]

system · 2019-03-25T08:27:41.813Z

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.