On 13-07-01 05:32 AM, Corey Richardson wrote:
> This is a copy of https://github.com/mozilla/rust/issues/7525, here
> for broader discussion.
>
> I propose to remove the float type from the language.
>
> float is defined by the manual as "the largest floating-point type
> that is directly supported by hardware on the target machine," but
> this isn't actually true (x87 supports 80-bit floats). I've seen it
> advertised as the "fastest float for the target," but performance also
> needs to include cache and bus pressure as well, not just speed of
> manipulation, and often the "fasted" in terms of manipulation is going
> to be some SIMD type using a coprocessor, and the situation gets even
> trickier if/when we have Rust being used for GPGPU kernels (LLVM has
> an R600 (AMD GPU) backend) or accelerator chips (a la Epiphany
> (parallella)). Furthermore it can cause confusion for incoming C/C++
> programmers who would expect float to be an f32.
The largest supported _of the rust types_; I didn't (and don't) intend
to have rust support f80 at all, since:
- It's not an ieee754 basic format.
- It's not a storage format; x87 loads and stores 32/64 bit values,
it's just an intermediate state during calculation on x87 stack.
You can't meaningfully observe it. It's an operating mode / codegen
thing.
- It doesn't exist on any non-x86 hardware anyways, and is deprecated
(for over a decade now) on x86. SSE2 is mandated in x64.
The reason for float, though, was: if you want to write "best effort"
code that's portable between targets with different best-precision, and
don't want to duplicate your code. Yes, you lose the ability to reason
as as closely as you might concerning precision, but most of the time we
use approx_eq and epsilon and get on without considering that exactly
anyways.
That said, I've done some meandering through architecture manuals and I
can't find any serious / living architectures that "only" support 32bit
fp. They all have modes that pair 32bit fp registers and support double
precision mode (arm vfp, mips, etc.) So the 32/64 angle isn't really ...
as pressing as I expected. So I assume anyone who's "writing f32 code"
is doing so intentionally these days. I.e. they don't _need_ it for
hardware reasons, they just _want_ it, for speed or interop.
The one other thing 'float' may help with is the (possible) future shift
to f128 that's a supported basic format in the revised 754-2008 spec. I
can't really speculate on how likely that shift is; f64 has held up
pretty well since the 80s.
> Variable width floating point code is also dangerous - frequently code
> has implicit assumptions about accuracy. Using floating point
> correctly is already hard enough, introducing variable width types
> makes it even harder.
I don't believe it changes the difficulty. Surely you do not regularly
look at decimal literals you type in and eyeball whether they overflow
23 bits of significand vs. 52 bits. You know they're inaccurate and you
have to do things like approximate comparisons in various circumstances,
and organize your arithmetic to avoid precision-loss the same way.
> I would remove float entirely, instead using f32 and f64 exclusively,
> also removing the f suffix for float literals. This allows user code
> to typedef float to what they want.
This doesn't make sense to me. You generally don't want to typedef a
platform-agnostic type to a platform-variable type if you can avoid it:
it makes the "will it build?" question platform-specific. By keeping
float _type-disjoint_ from f32 and f64, you put in all the relevant
conversions at library boundaries (though some of them will compile to
no-ops). The only other option here would be to introduce silent
coercions between fp widths, which sounds ghastly.
I think if we can find use cases for writing "float" in your code (i.e.
"best effort" or "don't care") then we should keep the concept. But if
not, maybe you're right and it should go. I'm curious how much weight
the f128 argument holds with people. Or if there were f32-only
architectures I overlooked.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
