Mea Culpa, minutes, & RFC...

[r754@xxxxxxxxxxxxxx]

        First, let me apologise for making a mistake in the text of the
        NaN proposal.  It was my intent that the proposal only say "it
        shall be POSSIBLE" to read & write the strings given.  It was
        not intended to say you "SHALL" read & write them, thus
        invalidating other possibilities such as NaN payloads & signs or
        internationalization & locales.  Thank you Jim for pointing this
        out to me.  I will rewrite & resubmit the proposal in the coming
        days & include anything Jim says should be in it.

        The minutes of today's meeting are included below.

        Near the end you will find what amounts to a request for comment
        from Prof Kahan seeking information on intended use of decimal
        arithmetic & formats by those who believe they will be customers
        of that portion of the standard.  If you are such a customer,
        please return your comments to this mailer (stds-754@xxxxxxxx).

        Do most people agree that 'consensus' is spelled with one 'c' &
        3 's's?

        Just curious...

                                Dan

        ---------------------------------------------------------------

        Notes for meeting at Sun in Menlo Park on Thursday 8/18/05 in
        the Sequoia Room in Building 14.  David Hough hosted us.  Jon
        Okada, Prof Kahan, Jim Thomas, Peter Markstein, Ivan Godard,
        Alexander Fit-Florea, Eric Schwartz, Dick Delp, Jeff Kidder,
        John Crawford, & Dan Zuras attended.  Mark Erle, Mike Cowlishaw,
        Peter Tang, Mahesh Bhat, Ricardo Morin & Steve Carlough were on
        the phone.


        I arrived 45 minutes late & everyone was deep into a discussion
        that seemed to be around Prof Kahan's issue.  A discussion of
        consensus ensued.  Ivan & Jeff suggested something along the
        lines of a Wiki for the standard & its issues.

        Dave took a slight detour to discuss the expiration dates of the
        ballots.

        Prof Kahan believes that we are reaching a consensus on limiting
        our consideration to a short list of languages (C, Java, Cobol,
        & Fortran, for example) & spend less time on other languages.
        Dave pointed out that there has been no consensus in the last 5
        years on modes & flags & none on the horizon.  I asked Jim &
        Ivan about the issue of what we BELIEVE we should do & what we
        should leave to the language committees.  Ivan invoked the
        principle of confining ourselves to those issues of portability
        & no other.

        After the 3:00 pee break, we went on to decimal.  John Crawford
        was here to present work by Mahesh Bhat & Ricardo Morin (who
        were on the phone) about decimal in Java workloads.  After an
        introduction by John, Ricardo presented the slides on their
        work.  It appears to be Java BigDecimal in 3 contexts, one of
        which was SPECjbb2005.  Another was SPECjAppServer2004.  As well
        as a financial application called the Morgan-Stanley Trade
        Completion (TC).  The highest decimal usage was SPECjbb2005 with
        9.4% (of which 4.7% was actual math).  TC only took a neglegible
        0.03%.  In spite of the 9.4% figure for SPECjbb2005, replacing
        all BigDecimal with float got a 15% speedup which suggests that
        there is some (mostly) GC time spent on BigDecimal that cannot
        be easily accounted for & might also be reduced when one went to
        some sort of small fixed length decimal type.  I suppose one can
        conclude from that that 15% is something of an upper bound in
        performance improvement that one can expect in an efficient
        hardware implementation.  Ricardo concludes that the use of
        BigDecimal is, at best, low to modest.

        Around 3:50, Peter presented his BID for Telco on Itanium & IA32
        slides.  Things seem to be in the 2x to 3x improvement range for
        each of the decimal parts individually (over the original
        format) but, of course, this amounts to only a few percent in
        the benchmark as a whole.

        At 4:00, Mike went to bat for the other team.  His presentation
        was on point for SPECjbb2005, BID, & the need for hardware.
        Unfortunately, much of his argument was lost in transmission so
        I'm a little unclear on the nature of his numbers.  His numbers
        differed from Ricardo's but there was no apparent contradiction
        just a (large) difference in assumptions.

        Eric took over at 4:25 with the 9th slide in Mike's set.  His
        arguments took on binary versus decimal for implementing decimal
        (primarily in hardware but he believes that his argument applies
        to software as well).

        At 4:45 Prof Kahan summarized that existing information provides
        us with no evidence for a market for fast & efficient decimal
        floating-point in hardware.  He concludes in the absence of such
        evidence that we, as a standards body, should standardize the
        arithmetic but not the formats.

        He also asked if there are any likely customers for Decimal128
        if it is there intention to replace all (or most) of their
        existing decimal storage formats (which range in size from 4 to
        121 bits) with the Decimal128 format or if they merely see the
        Decimal128 format as a computation format.

        Ivan suggested that a 32-digit format might be easier to
        implement for more people than a 34-digit one.  This was
        discussed as a possibility of a double extended for decimal.

        Around 5:15, I talked about my conversation with Darren Schmidt.