No subject

Vaughan Pratt prattacs.Stanford.EDU
Fri Feb 21 11:34:00 PST 1997


	From: "Russell L. Carter" <rcarteraconsys.com>

	Hmm, I've run a lot more x86 code through LAPACK than just the
	test and timing problems and have never had a problem.  This is
	using various versions of gcc on various PC unices.  I did have
	a problem with some of the eigenvalue test routines, but since
	I didn't need them, I ignored them.

This is anecdotal evidence.  That a package works for one happy user
(or mostly happy in this case) is little consolation to users for whom
it doesn't.  The objective way to test a package is to torture it on
an official rack, not on one's own software.

	Should 95% of the people on the planet either have their
	current Java machine run slower by at least a factor of 2 or
	replace their current machine with Sun approved hardware in
	order to make sure that broken programs do not arouse suspicion
	by running (slightly) differently on different available
	platforms?...  Those who know x86 performance are probably
	wondering why I only quote a factor of 2.  You're right, it's
	likely a bigger hit than that.

Apparently the performance impact of suboptimal floating point is
highly variable.  Intel arrived at their celebrated 27,000 year period
for encountering the Pentium division bug by estimating that in typical
use a spreadsheet would perform 1,000 divisions a day.  With that
frequency, or even a much higher one, one would not see a noticeable
slowdown with Mathworks' division bug workaround installed to eliminate
the problem.

Now we are being told that a workaround correcting for the vagaries of
80-bit extended precision will slow Java programs down by a factor of
2.  It is hard to believe that Java programs are *that* much more
numerical than spreadsheet programs.

Apparently people make up whichever extreme statistics support their
case as they go along, and have no shame when the two extremes differ
by however many orders of magnitude it takes to get from 1000 divisions
a day for a spreadsheet to a factor-of-two slowdown for a Java applet.

Carter's overall argument is part technical and part polemical.  That
the above two flaws occurred in the technical parts, which I could
understand, greatly undermined for me the credibility of the polemical
parts, which I could not.

Vaughan Pratt



More information about the Numeric-interest mailing list