Re: IEEE128 binary float to decimal float conversion routines

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Mon, 2015-11-16 at 22:42 +0000, Joseph Myers wrote:
> On Mon, 16 Nov 2015, Christoph Lauter wrote:
> 
> > For what it's worth: some colleagues of mine and myself have recently
> > published a paper on exact binary-to-decimal conversions between all IEEE754
> > formats, assuming BID as the encoding for decimal. None of the algorithms we
> > proposed uses a table larger that a couple of dozens of kilobytes. Converting
> > between binary and decimal FP with correct rounding is essentially the same
> > problem, so people might wish to have a look at these results:
> > 
> > > http://www.computer.org/csdl/trans/tc/preprint/07271015-abs.html
> 
It took a while to get this from behind the paywall ...

At this time I can NOT say this analysis applies to my case
(IEEE754-2008 Densely Packed Decimal floating point) 

This paper is focused on the Intel-centric BID format the assumes
software emulation.

POWER has been shipping full IEEE Decimal Floating point Hardware since
2007 and libdfp has been available since that time-frame.

Also this paper fails to mention (or cite) the decades of published
research by the esteemed Michael F. Cowlishaw. Mike and IBM brought the
original Decimal Floating Point proposal to the IEEE committee and
contributed DecNumber to open source communities to support Decimal
Floating point adoption.

http://speleotrove.com/decimal/

This over site and direct statements in this paper that you assume BID
format an later assumption that you can use binary (bit) shifts (vs
decimal digit shifts) raise doubts about the applicability of this
specific analysis.

Christoph, if you are interested in new analysis extending to
IEEE-754-2008 DPD implementation and performance. Let me know. I can
provide access to the latest public documentation and POWER systems for
testing if needed.


> Thanks.  I'm not at all expert on decimal floating-point or on its state 
> in the GNU toolchain (I just noted the absence of these conversions in the 
> course of reviewing patches for __float128 libgcc support for powerpc).  
> My general impression is that the IEEE 754 conformance state is probably 
> similar to or worse than that for binary floating-point - that is, various 
> miscellaneous local issues along with the same general issues of 
> optimizations not respecting the state involved in exceptions and rounding 
> modes (but because decimal floating-point is less widely used, such issues 
> are less likely to have been found, especially if some code is correct for 
> binary floating-point and no-one thought about decimal when writing an 
> optimization, and especially when involving issues such as preferred 
> quantum that don't exist for binary).
> 

Joseph,

Please do not assume the Decimal Floating carries all the sins of the
much maligned IBM long double. 

Both the soft-dfp and PowerISA DFP implement the 5 IEEE (FE_DEC_*)
rounding modes. The only caveat that I am aware of is that the HW and
soft-dfp (via the underlying DecNumber library) have additional rounding
modes that are not available at the fe_dec_setround API. This includes
the "Round to Prepare for Shorter Precision" mode, which we will expose
to address some of your concerns about double rounding in conversions.

And preferred quantum is automatic in the implementation or easily
enforced via quantize or quantize immediate instructions.

We are happy to get bug reports about the libdfp implementation and will
work with you to resolve them.

But we have a strong bias toward leveraging our high performance Decimal
hardware and existing libdfp infrastructure.

The _Decimal128 operation are already faster (POWER8) then equivalent
operation on Haswell for BID _Decimal128 (20x for add, 5x for multiply)
or in _float128 from libquadmath (12x for add, 6% for multiply). 

This trend will continue into next generation of processors and as we
implement the PowerISA3.0 quad-precision floating point in hardware, we
expect even better results.

So why would I even consider using software emulation to get one
additional ULP of accuracy?

I get very few complaints about proper rounding. I do get constant
pressure to improve performance. 

I would consider using precision extension techniques that leverage
PowerISA and POWER hardware. For example leveraging the DFP unit's fast
add/multiple/digit-shifter to get 64 or 96 digit precision for internal
operations. I have not coded this yet, but it does not look that hard to
do on existing hardware.

Also looking forward to PowerISA3.0 Quad-precision fussed multiply-add
can be used to deliver 226 bit resolution (al la IBM long double) for
internal conversions.

So we will work on resolving the issues that you have raised, but within
the context of leveraging PowerISA and POWER hardware capabilities.