in reply to Re: Decimal Floating Point (DFP) and does Perl needs DFP?
in thread Decimal Floating Point (DFP) and does Perl needs DFP?

Hello syphilis,

Now, your answer is what I was looking for!

This isn't about finding fault with the current Perl implementation, but about the possibility of improving the future of Perl5.

Were you able to view the referenced article? If not, I'll try to get a pdf of the article for you.

IBM added 54 DFP instructions and the XLC compiler uses them. I haven't looked at 'C' code in more than 20 years, but the idea of getting 34 digits of decimal accuracy when using Perl is down right 'sexy'. What was interesting in the wiki article was that the hardware was 76 times faster than the software for the demo. The wiki is from power6, and power7 was twice the speed of power6, and power8 is more than 3 times the performance of power7. But what is also interesting is that the software implementation is supported by Linux. So if some OpenPower hardware company developed a DFP plug-in, then Perl could have hardware Decimal Floating Point in the future on less expensive hardware. Developers could use the software versions for design/development/testing, and then production could use the hardware.

You gave me a lot to look into, so thanks for your work on this subject.

Regards...Ed

"Well done is better than well said." - Benjamin Franklin

  • Comment on Re^2: Decimal Floating Point (DFP) and does Perl needs DFP?

Replies are listed 'Best First'.
Re^3: Decimal Floating Point (DFP) and does Perl needs DFP?
by syphilis (Archbishop) on Jan 17, 2015 at 03:38 UTC
    Were you able to view the referenced article?

    Yes, but the only IBM (I think) processor that I have is a ppc64 on an old mac box - now running Debian Wheezy with gcc-4.6.3.
    I think that pre-dates the hardware improvements that you're talking about. Certainly, the _Decimal64/128 operations on that box are generally slower than on my (newer) Intel (Windows) and AMD (Ubuntu) boxes.
    My ppc64 processor does, however, utilise IBM's favoured "Densely Packed Decimal" format instead of Intel's/AMD's preferred "Binary Integer Decimal" format.
    DPD format is really nice - I can encode/decode that fairly quickly using a hash lookup, whereas BID format necessitates that the value be calculated.
    I assume that each of my processors has some special capacity to handle DFP operations, and that gcc is making use of that capability - but there's no guarantee that either of those assumptions is correct.

    the idea of getting 34 digits of decimal accuracy when using Perl is down right 'sexy'

    I agree, and Math::Decimal128 will give you that - but only for the basic arithmetic operations at the moment.
    Perl will improve markedly when someone gets around to (optionally) providing DFP processing built into perl. (But I think the time for that is not yet quite right.)

    You've actually now got me wishing I had a power8 box to play with.
    Which OS should it run to best test/experience these IBM capabilities ? ... AIX ?
    Is power8 bigendian ?

    Cheers,
    Rob

      Hello syphilis,

        ...slower than on my (newer) Intel (Windows) and AMD (Ubuntu) boxes...

      While searching the IBM site, I found a Redbook that describes the use of the DFP hardware and software. It stated that 3 Linux distributions ( Redhat, SUSE, and Ubuntu ) support the hardware and software DFP. It had a link to download the software, which if the hardware is present, will use the hardware, otherwise is does the calculation(s) in software. So it may be available for your Ubuntu system??? The Redbook stated that the software was designed to co-exist with binary floating point.

        Which OS should it run to best test/experience these IBM capabilities ? ... AIX ?
        Is power8 bigendian ?

      I honestly don't know enough now to give a good answer about which OS, but I'll be looking into the subject and hope to know more soon. The announcement letter for power8 says hardware supports both bigendian and littleendian. How, I don't know yet!

      The newest RS\6000 (p-series) that I have is power5 (bigendian), so I can't use any of the new features.

      Just so you know, Google, Hitachi and several other companies are coming out with non-IBM power8 computers during 2015. While IBM's entry level systems are around $10K, the non-IBM versions are projected to be less than $3K. Hopefully Google will want to dominate the market and build an entry level around the price point of Intel/AMD PCs. But that's just a wish!

      I don't have much time until March, but I am interested in furthering this capability for Perl, so lets keep in touch.

      Best Regards...Ed

      "Well done is better than well said." - Benjamin Franklin

      Hello syphilis,

      Just a quick update. I went to this site and downloaded the code and successfully compiled using 'make -f Makefile.Linux' on a AMD server running Debian with gcc 4.4.5. It seems to contain the missing functions that you mentioned. I ran the sample, and it seems to work?????

      ~/dfpal# ./dfpsample 1.000001 60000 Version of DFPAL: 2.20 DFPAL is operating in software value of n4 = 9.000000000000000E+384 9E+384 * 9E+384 = Infinity 9E+384 * 9E+384 => Overflow DFPAL_TRP_INVALID is enabled! DFPAL_TRP_OVERFLOW is not enabled! DFPAL_TRP_INVALID is enabled! sign of n1 0 Zero value = 0 n1 is less than n2 n1 - n2 = -59998.999999 N1 - N2 = -59998.999999 original decimal64 n1=1.000001 minus n1 = -1.000001 It is still Overflow Now, it is not Overflow ~/dfpal#
      Don't know what the sample is supposed to do, so your knowledge of the subject would be greatly appreciated to show some light. At least it's a start!

      Regards...Ed

      "Well done is better than well said." - Benjamin Franklin

        Just a quick update. I went to this site

        Yes, I've been there too - but haven't tried any of it out.
        I gather these are libraries that you link to if you want enhanced DFP coverage. The "decNumber" package appears to be software only, while DFPAL can tap into available hardware capabilities, falling back to decNumber where necessary.

        The mpfr home page links to decNumber, along with a link to what is presumably Intel's equivalent.
        And there's links there to a couple of other decimal packages - MathCW and mpdecimal.
        So there's plenty of additional chasing up to do for anyone so inclined :-)

        BTW, the original wiki page that you linked to contains a nice little atodecimal implementation that works for both _Decimal64 and _Decimal128.
        Unfortunately it won't evaluate 'inf', 'nan', or scientific notation inputs correctly and, by the time I add the perl code to accommodate that limitation, it probably won't be much faster than what I'm already doing.
        But I think I might use it anyway as it's cleaner than what I've presently got.

        Cheers
        Rob