Decimal floating point on x86 and ARM?

By: rwessel (rwessel.delete@this.yahoo.com), December 20, 2020 1:44 pm
Room: Moderated Discussions
blaine (myname.delete@this.acm.org) on December 20, 2020 10:52 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on December 20, 2020 8:25 am wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on December 19, 2020 9:48 am wrote:
> > > rwessel (rwessel.delete@this.yahoo.com) on December 19, 2020 7:54 am wrote:
> > > > dmcq (dmcq.delete@this.fano.co.uk) on December 19, 2020 3:41 am wrote:
> > > > > rwessel (rwessel.delete@this.yahoo.com) on December 18, 2020 6:57 pm wrote:
> > > > > > anon (an.delete@this.n.com) on December 18, 2020 8:29 am wrote:
> > > > > > > I read that C2X (the next C language revision) will add support for decimal floating point.
> > > > > > > I know that POWER and SPARC CPUs have hardware support for decimal FP,
> > > > > > > but are there any plans to include it on future x86 or ARM CPUs?
> > > > > > >
> > > > > > > Also, which languages have native support (without libraries) for decimal FP right now?
> > > > > > > I know of COBOL, PL/I, Ada, C# and F#. Any others?
> > > > > >
> > > > > >
> > > > > > The ("floating") decimal type in C# and F# bear no resemblance
> > > > > > to the IEEE decimal format, and little to anything
> > > > > > we'd normally consider an FP format. The .NET format is
> > > > > > a 96 bit binary integer with a decimal scale (10**0
> > > > > > to 10**-28). Useful for currency, to be sure, but not meaningfully related to IEEE decimal FP.
> > > > >
> > > > > Oracle's number format is base 100 and adjusted so comparisons
> > > > > work easily as strings. It does have an exponent,
> > > > > but yep, oveall no resemblance. And databases are an especially important place for decimal numbers.
> > > >
> > > >
> > > > As I've frequently* pointed out, there's not actually any
> > > > need for decimal numbers, but decimal scaling *is*
> > > > important. For something like a database column, that scaling
> > > > factor is probably best stored in the attributes
> > > > for the column. (at least for most purposes). For computational purposes it makes sense to store the scale
> > > > explicitly, but for a storage format you'd generally want to normalize** the number first.
> > > >
> > > >
> > > > *Not to worry, it's a bit of a hobbyhorse for me.
> > > >
> > > > **Not quite the same definition as for FP, but scaling and rounding so that the (computational)
> > > > scale factor (exponent) is the same as that of the storage format.
> > >
> > > About a year ago a spent significant part of my evening/night hours looking at speed
> > > of decimal scaling of products of quad-precision integers on modern x86-64 hardware.
> > > Conclusion - it can be quite fast. No special hardware/instructions required.
> > > If existing [quad-precision, i.e IEEE 754 decimal128 BID] decimal FP libraries
> > > are slow that's only because they are not coded competently.
> >
> >
> > Unfortunately I'm not actually a fan of the IEEE DFP stuff. I think that the main use case for decimal,
> > currency, and currency-like things, should never actually leave an integer or rational format. It's a heck
> > of a lot better than trying to do currency in BFP (and worse, a too narrow BFP format), but still...
> >
> > Performance issues seem vastly overblown. As you mentioned
> > scaling is not that hard, scaling right (the most
> > common case) is just the division-by-reciprocal-multiplication
> > thing, and most of those are scaling by fairly
> > small powers of ten. And most intermediate results will
> > fit in a 64-bit integer (although certainly not all,
> > at least 128-bit support is imperative). In those cases, you're looking at a couple of multiplications and
> > bit of logic to get the rounding right. Binary to/from decimal
> > conversion is not that painful either, see Terje
> > Mathison work on the subject. And finally, even if neither
> > of the above were true, there are very few applications
> > where the actual fraction of decimal work is enough to worry
> > about (the very high cycle costs on Z for traditional
> > applications is a bit of an exception, but that's really a quite artificial problem).
> >
> > If decimal performance is really an issue, I think good support for multi-precision
> > integer arithmetic and assists for binary/BCD conversions would be a much better
> > investment than actual direct support for decimal-(ish) arithmetic.
> >
> > And if decimal performance is such an issue, why has Z's storage-to-storage
> > BCD facility basically remained a slug for decades?
> >
> > I'm not actually quite sure what IBM's real position is on the subject. Sure they were the major
> > force behind the DFP standard, and the source of two of the major implementations (although they
> > clearly share their DFPUs between POWER and Z), they did recently (z14s) add a new integer decimal
> > facility, using the vector* registers (as opposed to the z9-ish era DFP facility). It looks mostly
> > like a massively cleaned up version of the old BCD storage-to-storage instruction set.
> > They might still be pushing DFP for things like Java, but it seems a tacit admission
> > that for things like Cobol and PL/I, DFP isn't really the answer.
> >
> > *IBM calls it the Vector Decimal facility, it's purely scalar, but using the wide vector registers.
>
> Just a note. If I recall correctly COBOL74 required 18 decimal digits of
> precision with the ability to not round. The main application is money.


Pre-Cobol 200x (I don't remember exact which version), 18 digits was, in fact, the requirement for storage fields. That was increased to 36 digits in the more recent standards.

The exact rules are a bit complicated, but up to a certain point the rule was that a computation needed to be performed exactly, and then rounded (or truncated) only when storing the result ("as if" rule applies). Thus if you multiplied three numbers with three digits after the decimal point, and stored that in a field specified with four decimals, the operation would need to produce a result with nine decimals, which would be rounded (in decimal) to the four place storage field.

That works equally for data and computations in decimal or binary formats, although decimal scaling and rounding is obviously easier (it becomes a simple shift) if you did the work in decimal.

The 18 digit requirement (and more or less precise intermediate result rule) is for character, BCD and binary formats, and basically requires a minimum of 61* bit binary support (assuming the platform supports binary numerics - in the past it was not required). For obvious reasons, that's usually a 64-bit int.

*Remember the sign.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Decimal floating point on x86 and ARM?anon2020/12/18 09:29 AM
  Decimal floating point on x86 and ARM?Per Hesselgren2020/12/18 10:16 AM
    Decimal floating point on x86 and ARM?anon2020/12/18 12:23 PM
      Decimal floating point on x86 and ARM?dmcq2020/12/18 06:18 PM
  Decimal floating point on x86 and ARM?rwessel2020/12/18 07:57 PM
    Decimal floating point on x86 and ARM?dmcq2020/12/19 04:41 AM
      Decimal floating point on x86 and ARM?rwessel2020/12/19 08:54 AM
        Decimal floating point on x86 and ARM?Michael S2020/12/19 10:48 AM
          Decimal floating point on x86 and ARM?rwessel2020/12/20 09:25 AM
            Decimal floating point on x86 and ARM?blaine2020/12/20 11:52 AM
              Decimal floating point on x86 and ARM?rwessel2020/12/20 01:44 PM
                Decimal floating point on x86 and ARM?blaine2020/12/20 05:29 PM
              Decimal floating point on x86 and ARM?Konrad Schwarz2020/12/21 04:17 AM
            Decimal floating point on x86 and ARM?Adrian2020/12/21 10:05 AM
  Decimal floating point on x86 and ARM?Konrad Schwarz2020/12/20 09:47 AM
    Decimal floating point on x86 and ARM?rwessel2020/12/20 11:28 AM
    Decimal floating point on x86 and ARM?Linus Torvalds2020/12/20 11:39 AM
      Decimal floating point on x86 and ARM?dmcq2020/12/20 12:06 PM
        Decimal floating point on x86 and ARM?Konrad Schwarz2020/12/21 03:31 AM
          Decimal floating point on x86 and ARM?Brendan2020/12/21 05:49 AM
            Decimal floating point on x86 and ARM?dmcq2020/12/21 07:59 AM
      Decimal floating point on x86 and ARM?Adrian2020/12/21 09:51 AM
        Decimal floating point on x86 and ARM?Linus Torvalds2020/12/21 12:12 PM
          Decimal floating point on x86 and ARM?Adrian2020/12/21 01:29 PM
          Decimal floating point on x86 and ARM?dmcq2020/12/21 04:13 PM
      Decimal floating point on x86 and ARM?David Hess2020/12/21 07:15 PM
        Decimal floating point on x86 and ARM?Konrad Schwarz2020/12/22 01:04 AM
          Decimal floating point on x86 and ARM?David Hess2020/12/22 01:05 PM
    Decimal floating point on x86 and ARM?blaine2020/12/20 12:40 PM
      Decimal floating point on x86 and ARM?Per Hesselgren2020/12/21 04:33 AM
        Decimal floating point on x86 and ARM?rwessel2020/12/21 06:17 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell tangerine? 🍊