On: Optimizations Enabled by -ffast-Math

[andraz]

The question is how to enable all this in Rust... Right now there's no simple way to just tell Rust to be fast & loose with floats.

[pornel → andraz]

There are fast float intrinsics: https://doc.rust-lang.org/std/intrinsics/fn.fadd_fast.html

but better support dies in endless bikeshed of:

• People imagine enabling fast float by "scope", but there's no coherent way to specify that when it can mix with closures (even across crates) and math operators expand to std functions defined in a different scope.

• Type-based float config could work, but any proposal of just "fastfloat32" grows into a HomerMobile of "Float<NaN=false, Inf=Maybe, NegZeroEqualsZero=OnFullMoonOnly, etc.>"

• Rust doesn't want to allow UB in safe code, and LLVM will cry UB if it sees Inf or Nan, but nobody wants compiler inserting div != 0 checks.

• You could wrap existing fast intrinsics in a newtype, except newtypes don't support literals, and <insert user-defined literals bikeshed here>

[kzrdude → andraz]

It must be clearly understood which of the flags are entirely safe and which need to be under 'unsafe', as a prerequisite.

Blanket flags for the whole program do not fit very well with Rust, while point use of these flags is inconvenient or needs new syntax.. but there are discussions about these topics.

[atoav → kzrdude]

Also maybe you woild like to have more granular control over which parts of your program has the priority on speed and which part favours accuracy. Maybe this could be done with a seperate type (e.g. ff64) or a decorator (which would be useful if you want to enable this for someone elses library).

[andraz → atoav]

Maybe... or maybe there would be just a flag to enable all this and be fine with consequences.

[mjburgess → andraz]

..have you used Rust?

> just a flag to enable all this and be fine with consequences

Is probably the opposite of what the language is about.

[wongarsu → andraz]

Reasoning about the consequences along a couple functions in your hot path is one thing. Reasoning about the consequences in your entire codebase and all libraries is quite another.

[varajelle → andraz]

Rust is not really a fast & loose language where anything can be UB.

At least it doesn't need the errno ones since rust don't use errno.

[pjmlp → andraz]

The whole point of ALGOL derived languages for systems programming, is not being fast & loose with anything, unless the seatbelt and helmet are on as well.

[jamesmishra → andraz]

I don't know if most Rust programmers would be happy with any fast and loose features making it into the official Rust compiler.

Besides, algorithms that benefit from -ffast-math can be implemented in C and with Rust bindings automatically generated.

This solution isn't exactly "simple", but it could help projects keep track of the expectations of correctness between different algorithm implementations.

[vlovich123 → jamesmishra]

Rust should have native ways to express this stuff. You don't want the answer to be "write this part of your problem domain in C because we can't do it in Rust".