Faster float conversion operations

[m-ou-se]

Hi!

I've been playing around a bit with int->float and float->int conversions lately. The implementations I have now seem to produce shorter assembly and perform faster than those currently in compiler-builtins. Some of them make a very significant difference. For example: u128->f64 is about 4 to 5 times faster on my x86_64 desktop, and u64->f64 runs about a factor 3 faster for the i686 target. Many others seem to provide roughly 30% improvement in my initial benchmarks, at least on the hardware I have here.

For now I put them in this crate: https://docs.rs/floatconv/

I still want to optimize some more, do better benchmarks, and verify correctness better. But I figured it might be good to already ask some questions about potential integration into compiler-builtins:

• Should these optimized versions be integrated into compiler-builtins? If so:
• Can this crate simply depend on an external crate (like in this (draft) PR)?
• How would we check the performance properly? I can run benchmarks on the computers I have here, but I'm not sure if that's enough to prove it's better on all processor models, etc.
• How would we check correctness? For the conversions from a 32-bit value, I've checked literally every possible value against the current implementation, but for 64 and 128 bit that's infeasible. Testing a lot of (generated) edge cases helps, but would that be enough? Or would this require some kind of formal proof?

[bjorn3]

Can this crate simply depend on an external crate (like in this (draft) PR)?

I don't think so.

[eddyb]

cc @Amanieu @japaric @alexcrichton How would you like to proceed here?
Alternatively, should this be a @rust-lang/compiler decision, perhaps with an MCP?

[nagisa]

The original (Rust) implementations of anything in this crate were ported without any concern for performance on any platform. There was no effort in formally proving their correctness either.

As thus I wouldn’t really hold any new changes to a significantly higher level of standard. So testing/benchmarking just on one or two different architectures would be good enough IME.

[Amanieu]

I think it's possible to depend on an external crate but that crate will need to be modified to support Rust's build system. Have a look at how hashbrown does it.

[Amanieu]

Then again compiler-builtins involves quite a bit of magic so you'll want to test this in a rustc build.

[bjorn3]

compiler-builtins is special in that all crates except for libcore implicitly depend on it.

[alexcrichton]

I think it's a good idea to run benchmarks to verify that this performs as expected, but otherwise I agree that we don't need hugely rigorous testing. It'd be great to take this time to invest in the test suite to expand it from what it already is, but we should already at least lightly test these functions relative to the default implementation of compiler builtins.

Unfortunately I don't think depending on a crate will work. The compiler-builtins crate is specially handled with respect to codegen and how it's linked, but that logic doesn't apply to the dependencies of compiler-builtins. If this can't be easily integrated into this crate, though, we could try making submodules work.

[AaronKutch]

I have greatly improved integer to float testing in compiler-builtins. Does cargo test --release still pass the tests with the latest master?

[AaronKutch]

Actually, since I am refactoring the floating point code right now, I think I will tackle this and try to implement any speedups from floatconv

[AaronKutch]

Now that I look deeply into it, it seems floatconv has a refined int-to-float conversion, and configures native or soft conversion depending on platform. However, it seems to me that LLVM is already doing the native/soft configuration? I see it using fcvtzu instructions for all appropriate conversions with aarch64. note: compiler-builtins has some hardcoded configuration for x86_64, but none for aarch64, so does this indicate no hard-coded configuration is needed at all?

[m-ou-se]

I have greatly improved integer to float testing in compiler-builtins.

@AaronKutch Thanks :)

I'll check if it passes all the new tests, and update the PR to integrate the implementations directly into this crate.

[Shnatsel]

For the conversions from a 32-bit value, I've checked literally every possible value against the current implementation, but for 64 and 128 bit that's infeasible. Testing a lot of (generated) edge cases helps, but would that be enough?

Fuzzing can help discover interesting edge cases. The Rust Fuzz Book will get you started.

You can use fuzzing to determine that your implementation matches the values produced by the current implementation with a simple assert!().

Update: I've opened an initial PR for fuzzing: m-ou-se/floatconv#4

[AaronKutch]

That LLVM based fuzzer is good for general structural fuzzing where it tries to hit all code paths. There is also a fuzzer in compiler-builtins I specially built for the purpose of fuzzing floats https://github.com/rust-lang/compiler-builtins/blob/master/testcrate/src/lib.rs. This fuzzer is structured around the sign, exponent, and significand, has an edge case tester for extremes that random values would be unlikely to trigger, and has my or-and-xor-rotate fuzzer that is better than feeding plain random values

[m-ou-se]

Closing in favour of #464