If I understand this API correctly, Java won't get a distinct float16 type. It seems that they'll have 16 bit floats encoded in shorts (16 bit integers).
This seems like it could be a huge footgun. A lot of methods already have an overload for short, so a completely separate set of functions are needed to do operations on them.
I get that it's hard to introduce a 16 bit float as a new primitive type in the JVM, so that's most likely not an option.
.NET introduced 16 bit floats as the "Half" type 2 years ago [1] and I think their approach is far superior. They're also saving it as a (u)short internally [2], but they have something that Java (still?) does not have: They made it a user-defined value type, or when using C# language: a struct.
This doesn't create footguns because it is a separate type and also doesn't have any meaningful overhead. And since .NET 7 will introduce generic math [3], we'll seem to be able to use the same APIs as we've always done.
IMHO, this is an API - just like Optional<T> - which could be far better designed if project valhalla would already be a thing.
> It seems that they'll have 16 bit floats encoded in shorts (16 bit integers). This seems like it could be a huge footgun.
I agree, fortunately the upcoming Primitive Classes [1] will make it possible to create a float16 type by wrapping a short without any overhead, thus acting essentially as a type safe alias.
It's also likely that the JDK will come with an ad'hoc type as the Vector API seems to currently be considering adding a HalfFloat class [2] so that you can leverage float16 directly with SIMD logic which is obviously one of the major benefits. See JDK-8290204 [3] for more details about it.
It's a bit too late to try and shoehorn half-floats into the mix.
They are super good for so many things but to have converting back and forth for different systems is over engineered, so before ALL systems support them they probably wont take off.
It's a chicken and egg problem. Khronos should have thought about it earlier!
In my particular case Raspberry 4 GPU does NOT support them in drivers yet. And I cannot rely on them being implemented properly.
Float16s are useful in ML and compute workloads where they make it possible to double the throughput of vector based instructions (SIMD in CPUs / GPUs) at the cost of a lower precision which can be acceptable for many such workloads.
Exactly so, there are a bunch of Java interfaces to native ML libraries that have some messy bit hacking to convert between fp16 and Java floats. This API along with the intrinsification (https://github.com/openjdk/jdk/pull/10500) will mean I can throw away that code and replace it with something that performs correctly and is much faster.
This seems like it could be a huge footgun. A lot of methods already have an overload for short, so a completely separate set of functions are needed to do operations on them.
I get that it's hard to introduce a 16 bit float as a new primitive type in the JVM, so that's most likely not an option.
.NET introduced 16 bit floats as the "Half" type 2 years ago [1] and I think their approach is far superior. They're also saving it as a (u)short internally [2], but they have something that Java (still?) does not have: They made it a user-defined value type, or when using C# language: a struct. This doesn't create footguns because it is a separate type and also doesn't have any meaningful overhead. And since .NET 7 will introduce generic math [3], we'll seem to be able to use the same APIs as we've always done.
IMHO, this is an API - just like Optional<T> - which could be far better designed if project valhalla would already be a thing.
[1]: https://devblogs.microsoft.com/dotnet/introducing-the-half-t... [2]: https://github.com/dotnet/runtime/blob/d783badaa38596beedefd... [3]: https://devblogs.microsoft.com/dotnet/dotnet-7-generic-math/