[ofiwg] the problems with atomics
jeff.science at gmail.com
Tue Jul 7 12:56:45 PDT 2015
Why support long double at all? It's sounds like a mess no matter how we do it. Does anyone even support atomic a for this type in network hardware?
ISO Fortran 2008 contains float128 and I think that fixed width types are much more sane, so why not focus on float128?
I am optimistic that float128 will become more important in MPI-4, FWIW.
Sent from my iPhone
> On Jul 7, 2015, at 12:41 PM, Hefty, Sean <sean.hefty at intel.com> wrote:
> libfabric defines several datatypes for atomic operations. For the integer types, the size of the data type is included as part of the definition -- INT8/16/32/64. For floating point types, no size is provided -- float/double/long double. I have added sizes to float (32) and double (64).
> Long double presents a wonderful challenge (i.e. mess). On x86, a long double usually converts to an 80-bit value. However, PPC and SPARC define something completely different (106-bits?). IEEE defines a binary128 value, but in such a way that the 80-bit format is IEEE compliant, but PPC and SPARC are not. And, of course, this allows a compiler to choose a long double to mean a 128-bit value.
> But wait, there's more! The amount of space allocate for a long double may be either 96 or 128 bits. I'm not sure which alignment is more common, but I suspect 128-bit is for 64-bit platforms, and 96-bit is for 32-bit platforms.
> Returning back to the problem, a datatype of 'long double' isn't particularly useful without a clear definition of the size of the type and its alignment. The Long Double Challenge also suggests that libfabric should define multiple data types to cover the various cases.
> Someone feel free to chime in here with a brilliant solution for handling this that doesn't and up with this sort of datatype explosion:
> (To be clear, the x86 80-bit format probably isn't any weirder than PPC. The Intel architects probably just had more say in the IEEE standard.) I'm not sure the size at the endpoints matters, versus the size in the packets and the alignment.
> - Sean
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
More information about the ofiwg