gh-153740: Optimize PyFloat_Pack/Unpack2 using native _Float16

[skirpichev]

• Issue: Conditionally support native half-precision IEEE types in struct/array/ctypes modules and memoryview #153740

[skirpichev]

Not sure how to fix this error:

/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x25
Objects/floatobject.o: in function `PyFloat_Pack2':
floatobject.c:(.text.PyFloat_Pack2[PyFloat_Pack2]+0x32): undefined reference to `__truncdfhf2'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

CC @StanFromIreland (fuzzers)

[StanFromIreland]

The configure probe only tests a compile-time _Float16 constant, so it reports "yes" in the OSS-Fuzz Docker container where clang accepts the type but the container's pre-GCC-12 libgcc lacks __truncdfhf2 which is the runtime helper the PyFloat_Pack2 double to _Float16 conversion links against. I suggest you make configure do a runtime double to _Float16 conversion.

[skirpichev]

I suggest you make configure do a runtime double to _Float16 conversion.

Good idea, that works.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit ac38cb8 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F154796%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[skirpichev]

!buildbot risc

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit 6bfff56 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F154796%2Fmerge

The command will test the builders whose names match following regular expression: risc

The builders matched are:

• RISC-V 64-bit Ubuntu PR
• riscv64 Ubuntu PR
• RISC-V 64-bit Ubuntu NoGIL PR
• RISC-V 64-bit Ubuntu Clang PR

[hpkfft]

This looks good.
I tested it using Intel's icx compiler and CFLAGS -mavx512f -mavx512fp16 and test_float passes.

[skirpichev]

CC @vstinner, does it make sense for you?

[vstinner]

CC @vstinner, does it make sense for you?

On the main branch, PyFloat_Pack2() is 107 lines long and PyFloat_Unpack2() is 55 lines long. It's the same C code on all platforms and the test suite pass on all platforms.

With change, PyFloat_Pack2() is 171 lines long and PyFloat_Unpack2() is 112 lines long. So this change makes the C implementation twice bigger and makes it depend on the C compiler (_Float16 support) and the architecture (add #ifndef __riscv).

What are the advantages of using _Float16?

[hpkfft]

A simpler implementation might be to fall-through to the "main" code path if the input is NaN. I think this would avoid the conditional compilation for __riscv. Something like the following:

int PyFloat_Pack2(double x, char *data, int le) {
#if HAVE_FLOAT16
    if (!isnan(x)) {
        _Float16 y = (_Float16)x;
        // etc.
        return 0;
    }
#endif

[hpkfft]

Building Python with this PR (as it's currently written) and -mavx512f -mavx512fp16, I see performance improve from 5.20 ns to 2.55 ns as measured by the following Google benchmark:

#include <Python.h>
#include <benchmark/benchmark.h>

static void BM_Pack2(benchmark::State& state) {
    char p[2];
    for (auto _ : state)
        PyFloat_Pack2(1.0, p, 1);
}
BENCHMARK(BM_Pack2);

BENCHMARK_MAIN();

on Intel Sapphire Rapids (which supports native float16 arithmetic and conversions).

[skirpichev]

What are the advantages of using _Float16?

Speed.

A simpler implementation might be to fall-through to the "main" code path if the input is NaN.

Good idea. The current patch looks close to other cases, where special handling of nans is required. But here an alternative implementation will be kept for a while, lets use this!

[vstinner]

Why do you change the compiler flags?

[skirpichev]

To disable optimizations.

[vstinner]

What are the advantages of using _Float16?

Speed.

In that case, you should rewrite your PR title to "Optimize PyFloat_Pack/Unpack2 using native _Float16", and provide a benchmark.