Fall back on C implementation of operators

[VariantXYZ]

In sonos/tract#916 I've been investigating fp16 math support with ARM hardware that supports it, and while it's not ready for a PR yet, I think that what I've found so far is promising.

By having a C file with simple functions like:

void add_f16(_Float16 *c, const _Float16 *a, const _Float16 *b) { *c = *a + *b; }

for add/sub/mul/div, and using them when a target arch or target feature is available (fp16 or fp16fhm?) would allow for significantly better performance in applications relying on the half crate (no need to convert constantly from f32 to f16).

When combined with LTO, it's possible to create applications and static libraries that properly embed and optimize these core operators, allowing for significant performance improvement on platforms that have hardware support!

The main problem is that not every toolchain supports _Float16, and so I'm worried that a combination of 'target supports fp16' + 'compiler does not support _Float16' will be true...

This would also add a dependency on the cc crate.

[starkat99]

I've been working on AArch64 implementations using inline assembly where intrinsics aren't available and it's working out well. Adding C sources just means having to deal with a multitude of C compilers, not all of which may support the operations, and would also add an unnecessary dependency on C compilation to this crate, which I'm not willing to do. Using intrinsics and assembly is more than sufficient to get the necessary functionality, which is already in progress.

[VariantXYZ]

Thanks for the info @starkat99 !

Re: intrinsic support, I wasn't aware of this since the only thing I could find on it was this PR: rust-lang/stdarch#344 which seemed to be stalled on the fact that a native f16 type didn't exist.

I'm also fairly new to Rust and I wasn't sure about how inline assembly would play with LTO, but I did notice that when I tried it with C + LTO that the core operators were embedded as if f16 were a natively supported type (with minimal or no casting at all in tight loops, just the half-width float instructions).

If there could be a significant performance improvement, would it be worth looking into as an opt-in feature? Of course, if assembly implementations already handle this, then I'll just look forward to that!

[kali]

Great news @starkat99, looking forward to play with this (and a significant item out of tract roadmap too !)