Mea Culpa, minutes, & RFC...
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' &
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
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
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.