I didn't use _Float16 because it's not generally available.

You could additionally introduce a dependency on Imath and let it handle the platform specific/intrinsic stuff if performance is the ultimate goal? And leave this non-Imath fallback if dependency is not wanted/available...

@kmilos I believe it's a little bit too much for a single rare case 🙂

Ah good point. We already have imath as an optional dependency via openexr, so I think just adding #ifdef HAVE_OPENEXR would be enough to let you use imath_float_to_half() and imath_half_to_float().

Does anyone know if imath has runtime dispatch? Ie. the SSE2 / AVX512 / whatever path is picked at runtime?

Does anyone know if imath has runtime dispatch? Ie. the SSE2 / AVX512 / whatever path is picked at runtime?

I don't think so.

I had a quick grep and I think it's probably using a look up table by default:

https://github.com/AcademySoftwareFoundation/Imath/blob/main/src/Imath/half.h#L116

You need to build with extra compiler flags to enable the use of intrinsics. Anyway, it's likely to be quicker than bit twiddling, and we probably already have this LUT inside the openexr loader, so it probably makes sense to use it.

You need to build with extra compiler flags to enable the use of intrinsics.

I guess -march and -mcpu determine if F16C extension is available or not. Been around for a while though...

Anyway, it's likely to be quicker than bit twiddling, and we probably already have this LUT inside the openexr loader, so it probably makes sense to use it.

Some idea of difference is already given by the same header file:

https://github.com/AcademySoftwareFoundation/Imath/blob/4d4e01c8c9fb9b9dbbefa2e135b21778c9cd331e/src/Imath/half.h#L162-L177

Once PR #3618 lands, another option would be to use Highway's PromoteTo() function, which will map to _mm{,256,512}_cvtph_ps() on x86.
https://github.com/google/highway/blob/b39942c49b6e6a24f9dec69b1a02143c8ad21eef/hwy/ops/x86_128-inl.h#L7942-L7945
https://github.com/google/highway/blob/b39942c49b6e6a24f9dec69b1a02143c8ad21eef/hwy/ops/x86_256-inl.h#L6025-L6034
https://github.com/google/highway/blob/b39942c49b6e6a24f9dec69b1a02143c8ad21eef/hwy/ops/x86_512-inl.h#L4624-L4633

This should be safe to use if its availability is verified at both compile- and run time with HWY_HAVE_FLOAT16 / hwy::HaveFloat16().

I might take a look at this, although 16-bit float TIFFs aren't that common.

it's likely to be quicker than bit twiddling

It's definitely quicker. But since 16-bit float TIFF seems to be an extremely rare case, I decided to not go hardcore here.

we probably already have this LUT inside the openexr loader

It uses ImfHalfToFloatArray. We could optionally use it if we have HAVE_OPENEXR defined

Ah I keep forgetting about highway, you're right.

But I agree with @DarthSim --- this is not likely to be a hotspot, so just do something simple for now. We can put in a highway path if this function ever shows up on profiles.

Applied some code style fixes