Subject: Java Numerics and x86

From: [email-masked] (Dave Brillhart - SMCC SE - Orlando)
Date: Sun, 23 Feb 1997 02:25:49 -0500

Russell L. Carter writes:

> Here we flirt with fundamental issues of computability.
> (...stuff deleted...)
> 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?

95% of the planet... Billy G. better get out his "will code for food"
signs :-)

I'm not sure I understand all the issues, but I've enjoyed reading the
last couple messages in this thread. Here are a few observations. BTW, I
do not represent Sun on these issues - I'm just an interested reader who
happens to work at Sun.

Your statement suggests a choice of performance OR numerical consistency.
However, these issues are orthogonal.

On the issue of performance:
  Assuming the vast majority (95%) of folks that use Java are running
  it on x86 or PowerPC platforms (and I imagine it may get there
  eventually), do you really think the Java FP model will cause the
  general Java user population to realize a 2x performance degradation?
  Would the typical user even notice a performance or numerical
  accuracy improvement if the Java spec allowed compilers to leverage
  fused multiply-add ops, extended precision registers, or other special
  features? Over what percentage of the target market for Java would
  your suggested FP model have a tangible effect? That's not a
  rhetorical question... the answer might surprise me.

  I understand this alias is for those interested in scientific computation
  using Java - and for these folks that live and die by FP performance,
  Pentium class machines are underwhelming at best. The PentiumPro is
  better, but the $/perf advantage over a RISC box is almost negligible,
  which may come as a surprise to some. An UltraSPARC-based workstation
  (143MHz, 64MB, 2G, 17", 10bT) is in the $5K street price range (even
  less for academia) with a SPECfp95 of 7.85. Compare that to a couple
  system configs (www.dell.com) for systems benchmarked by SPEC
  (www.specbench.org). There is also an interesting "250MHz UltraSPARC
  on a PC form-factor" motherboard that you basically just plug into a
  PC chasis (www.sun.com/sparc/SEUAX/index.html) offering 12.0 SPECfp95
  performance. You could probably build a complete system for about
  $6500.

    System            Processor    SPECfp_base95  ~Cost    $/fp
    ------------------------------------------------------------
    Ultra 1/143       UltraSPARC-143   7.85       $5000   $ 637
    SPARCengine AX    UltraSPARC-250  12.00       $6500   $ 542
    Dell XPS Pro200   PentiumPro-200   5.54       $3211   $ 580
    Dell XPS 200      Pentium-200      2.98       $3100   $1040

On the issue of numerical consistency:
  If I understand the arguments, the current Java FP model is designed
  to result in *consistent* numerical results on ALL platforms - even for
  broken programs (by which I assume you mean algorithms that have been
  shown to produce inconsistent results across various architectures and
  languages - due to aggressively optimizing compilers). You might be
  able to argue that Java produces consistently less precise results than
  are obtainable using extended precision registers, but your statement
  that switching to Sun approved H/W solves the consistency problem seems,
  well, inconsistent.

Until reading this thread, I didn't realize that Java code that is
extremely FP intensive will run about half as fast, today, on an x86
box as it has the potential to run. However, I imagine intelligent compilers
(for Java applications) and Java Virtual Machines (for Java applets) will
soon be (or already are) available that will do The Right Thing for the x86
architecture. The market (or possibly Microsoft's marketing engine?) will
prevail.

It was an interesting hypothesis that Sun is purposely "hamstringing" x86
and PowerPC Java implementations by mandating a sub-optimal FP model. If we
ignore the alleged performance motivation for a second, what would it cost
Sun (time to market, complexity, compliance testing, ...) if it allowed
platform-specific optimizations? And what would be the reward for that cost?

Regards,

-- Dave
      ______
     /_____/\      Dave Brillhart - Systems Engineer
    /____ \\ \     Sun Microsystems Incorporated, SMCC
   /_____\ \\ /    3504 Lake Lynda Drive, Suite 410
  /_____/ \/ / /   Orlando, Florida 32817
 /_____/ /   \//\
 \_____\//\   / /  Voice/Pager:   407-384-4644/800-314-1259
  \_____/ / /\ /   E-mail:        [email-masked]
   \_____/ \\ \    Urgent E-Mail: [email-masked]
    \_____\ \\     Internal URL:  http://turbo.east/~dcb
     \_____\/

---

From: "Russell L. Carter" <[email-masked]>
Date: Mon, 24 Feb 1997 09:57:45 -0700

>   general Java user population to realize a 2x performance degradation?

No, I should have added the qualifier "on floating point".

>   rhetorical question... the answer might surprise me.

The first curiosity here is the definition of "typical user".  It appears
to implicitly be defined as a non-scientific/engineering application user.
For the sake of argument, let's use that definition.
So... what about these users when they use image processing features
in multimedia applications?  I think the percentage of the target
market using multimedia applications might be rather high, though
I don't have any figures.  Certain supporting evidence does exist,
for instance, Intel's fixation on MMX and video conferencing.

The second curiosity is why the heart of the problem, the fact that
floating point operations are restricted to 53 mantissa bits, AND its
implementation on x86 as a store/read EVERY flop, is not mentioned.

>     System            Processor    SPECfp_base95  ~Cost    $/fp

This includes the price of software?  I specifically said "system".
Add in compilers, application software, etc. etc. and recompute.
I also note that the above table indicates that the price/
performance of the Ultra 1/143 is "underwhelming at best", and
comparing it to the Dell XPS Pro200 we see that it is already 9%
in arrears ->before adding on the cost of software<-.

This rather boring exercise in splitting benchmark hairs is necessary
because some have sought to represent the x86 architecture as 
inappropriate for "performance sensitive" floating point calculations.  
Ergo, the argument continues, the requirement that Java floating 
point on x86 require a store/load every flop is not a severe 
requirement, because more appropriate architectures exist for 
performance sensitive floating point.

>From the table you kindly supplied, I see that currently you get what you
pay for.  The effect of a store/load after every flop on x86,
measured by a hypothetical SPEC97java_fp suite, would be to reduce
the price/performance of x86 by a factor of maybe two.  I'd
say that was significant.

>   that switching to Sun approved H/W solves the consistency problem seems,

Switching to Sun approved H/W solves the performance problem induced
by the constant mantissa length requirement.  By definition, H/W is
irrelevant to consistency.  Rereading my previous 
mail, I don't see how this could have been misconstrued.

> architecture. The market (or possibly Microsoft's marketing engine?) will

The issue is very simple and there are no rabbits that can be pulled
out the hat by those clever compiler writers.  Requiring a store/load
every flop on x86 wrecks the floating point pipeline.

> platform-specific optimizations? And what would be the reward for that cost?

As noted before the problems associated with validating floating point
I/O routines are going to cause a lot more trouble than computing 
intermediate floating point results to 16 extra bits of precision.

The "reward" for Sun would be decreased sales due to the standard allowing
a level playing field for performance.  Which is exactly the reason
for this requirement, not because there is some mathematical
consensus that all intermediate floating point results must be 
performed to the same precision.

> -- Dave

Cheers,
Russell