[ofiwg] the problems with atomics

[Underwood, Keith D]

What is your preference for how to support long doubles for MPI RMA?

> -----Original Message-----
> From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-
> bounces at lists.openfabrics.org] On Behalf Of Jeff Hammond
> Sent: Tuesday, July 07, 2015 3:57 PM
> To: Hefty, Sean
> Cc: ofiwg at lists.openfabrics.org
> Subject: Re: [ofiwg] the problems with atomics
> 
> 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.
> 
> Jeff
> 
> 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:
> >
> > FI_LONG_DOUBLE_80BITS_ALIGNED_96,
> > FI_LONG_DOUBLE_80BITS_ALIGNED_128
> > FI_LONG_DOUBLE_96BITS_ALIGNED_96,
> > FI_LONG_DOUBLE_96BITS_ALIGNED_128,
> > FI_LONG_DOUBLE_128BITS_ALIGNED_128,
> > FI_LONG_DOUBLE_WEIRD_PPC_ALIGNED_128
> >
> > (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
> > http://lists.openfabrics.org/mailman/listinfo/ofiwg
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg