<div dir="ltr"><div>FWIW, I recall discussion of 16-bit floats at an AO real time computing meeting I was at a few years ago. The take home I got was that high end GPUs support 16-bit floats, and they are especially advantageous in this application as you're trying to do really fast matrix-vector-multiply operations, and if you can keep the matrix in cache then you're no longer memory bandwidth limited. Obviously, storing values at 16 bit rather than 32 gets you a factor of two advantage here. Point being I don't think it's true in the general case that hardware support is not either already there or coming.</div><div><br></div><div>But also I would argue that's not especially relevant. As pointed out previously, the option to store 16-bit floats has applications in FITS as a transport standard, irrespective of whether you end up converting them to 32 bit internally or not.</div><div><br></div><div>Aloha,</div><div> Paul</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 28, 2025 at 2:28 AM Richard J. Mathar via fitsbits <<a href="mailto:fitsbits@listmgr.nrao.edu">fitsbits@listmgr.nrao.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There are two pairs of shoes here: i) support of the 16bit "half" float on <br>
processors is very unlikely to happen, because on every architecture in the past the <br>
designs went towards wider float types. (AI may change that ..?)<br>
<br>
ii) support of the 16bit float in libraries (C23 for example) is added by implementing<br>
parsers that expand these to 32bit "single precision" float and continuing artihmetics<br>
with the "single precision" floating point libraries. This is for example the<br>
current ARM status <br>
<a href="https://developer.arm.com/documentation/100067/0611/Other-Compiler-specific-Features/Half-precision-floating-point-data-types" rel="noreferrer" target="_blank">https://developer.arm.com/documentation/100067/0611/Other-Compiler-specific-Features/Half-precision-floating-point-data-types</a><br>
and the gcc handling<br>
<a href="https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html</a><br>
<br>
iii) In the TIFF format there are rumors in <a href="https://pypi.org/project/tifffile/" rel="noreferrer" target="_blank">https://pypi.org/project/tifffile/</a><br>
(see "Notes") that TIFF supports 16bit floats, but I suspect this claim is wrong; <br>
I have not found a TIFF documentation to support that view.<br>
If the TIFF file supports these floats, one may use the Foreign File Encapsulation <br>
Convention of <a href="https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html</a><br>
to include TIFF images in FITS files. This is very efficient because<br>
TIFF supports a wide range of compression algorithms.<br>
<br>
In summary, even if the storage format is supported (as disk capacities <br>
and streaming bandswiths *are always* an issue), there will be a small run-time <br>
overhead by parsing the 16bit-floats in and out of their 32bit-float processor registers.<br>
<br>
Richard Mathar<br>
Heidelberg<br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.nrao.edu" target="_blank">fitsbits@listmgr.nrao.edu</a><br>
<a href="https://listmgr.nrao.edu/mailman/listinfo/fitsbits" rel="noreferrer" target="_blank">https://listmgr.nrao.edu/mailman/listinfo/fitsbits</a><br>
</blockquote></div>