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 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 two 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.