std.math performance (SSE vs. real)

[Iain Buclaw via Digitalmars-d]

On 29 June 2014 22:45, Russel Winder via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Hopefully there are points here for pedantry and bloody mindedness…
>
>
> On Sat, 2014-06-28 at 18:32 -0700, Walter Bright via Digitalmars-d
> wrote:
> […]
>> Keep in mind that D is a systems programming language, and that
> implies you get
>> access to the hardware types.
>
>
> On Sun, 2014-06-29 at 12:22 -0700, Walter Bright via Digitalmars-d
> wrote:
> […].
>>
>> That is not  true with D. D specifies that float and double are IEEE 754 types
>> which have specified size and behavior. D's real type is the largest the
>> underlying hardware will support.
>>
>> D also specifies 'int' is 32 bits, 'long' is 64, and 'byte' is 8, 'short' is 16.
>
>
> D gives access to the hardware types, and D defines the structure of all
> those types. The only resolution is that D only works on that hardware
> where the hardware types are the ones D defines. Thus D only works on a
> subset of hardware, and can never be ported to hardware where the
> hardware types differ from those defined by D.
>
> So D float and double will not work on IBM 360 unless interpreted, and
> real would be 128-bit (not IEEE)?
>

I'm sure it isn't as bad as you describe for floor and double.  And if
it is, then I can't see GCC (C/C++) working on IBM 360 either, without
some out-of-band patches.  And so what you allege IBM to have done is
a platform problem, not a language one.

Support for IBM extended reals is partial, and will improve as PPC is ported to.


> The D real type definitely suffers the C/C++ float and double problem!
>
> I guess we just hope that all future hardware is IEEE754 compliant.
>

else
  static assert(false, "Here's a nickel, kid. Go buy yourself a real
computer.");  // :)