[ofiwg] the problems with atomics

[Jeff Hammond]

Once you tell me unambiguously what sizeof(long double) is without
referring to particular compiler+processor+OS combination, I'll be
happy to answer that question :-)

Seriously, "long double" is a stupid feature and whoever decided that
it was a good idea to standardize in ISO C without bothering to attach
any sort of requirements on what it is was a moron.  Seems like a
textbook case of design-by-committee failure.  People need to read
https://en.wikipedia.org/wiki/Long_double and see if they can lobby
hard for supporting this feature with a straight face.  What happens
when somebody decides to make a processor+compiler+OS where long
double has 65 bits of accuracy but uses 4097 bits of storage?  Should
OFI try to support that?

Fixed-width floats are sensible.  I would love to see float128
supported.  I'll let someone else at Intel lobby for float80, but I
can't imagine a scenario where I'd use it.  If float128 is supported,
one can always promote double double into that and not lose bits, and
I think this is the only way in which we should try to support double
double, in case this is on anyone's mind.

Frankly, this debate has inspired me to want to deprecate long double
from MPI in favor of something that actually makes sense.

Jeff

On Tue, Jul 7, 2015 at 1:01 PM, Underwood, Keith D
<keith.d.underwood at intel.com> wrote:
> 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



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/