Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!seas.gwu.edu!gritz
From: gritz@seas.gwu.edu (Larry Gritz)
Newsgroups: comp.sys.hp
Subject: README: Hazard in 68040 upgrades for HP9000/400t!
Keywords: 68040, HP9000/400t
Message-ID: <3270@sparko.gwu.edu>
Date: 5 Jun 91 15:53:24 GMT
Distribution: na
Organization: The George Washington University, Washington D.C.
Lines: 97

We have a cluster of HP9000/400 series workstations, including the following:
	3 HP9000/433s
	2 HP9000/425t
	5 HP9000/400t diskless nodes

We have put in procurements for upgrades of all these workstations to 68040
processors (400t -> 425t).  So far, two of these upgrades have arrived and
were installed.
   At first, we were very happy with the two- to three-fold increase in speed.
Then, one by one, we started to come across programs that ran slower on the
64040's.  Not a little slower, but TEN TIMES SLOWER OR MORE!
   The most dramatic was a program which read in five vectors of about 50000
doubles, computed some statistics, then wrote a similar number of double to
an ASCII files.  The calculations took practically no time, but the disk write
operation took a half hour!  (It took about 3 minutes before the upgrade.)
The program would just sit there, with very intermittant short writes to the
disk.
   At first, we thought it was a problem with writing the files, but it turns
out that many functions that were done in floating point hardware before the
upgrade are not NOT USED ON THE 040, and are EMULATED IN SOFTWARE.  Among
these functions are all trig functions and some routines that are needed by
fprintf.  (These were our problems.)
   We called HP, who were not helpful at all.  The gave us a runaround, and
were generally not interested.  The support people said, "we deal with bugs,
not performance problems."  But if we spend a couple thousand bucks on an
upgrade, and afterwords certain programs run ten times slower, that's a
big problem!  HP told us "calculations with doubles aren't a common 
operation."  ON AN ENGINEERING WORKSTATION???  Who are they kidding?
   The director of our department wants to give his upgrade back and get the
030 back in his machine because his programs ran faster before the upgrade.
We are considering cancelling the rest of our 68040 upgrade orders.  I urge
all of you to think very carefully before buying the 68040 upgrades.
   Comments?  Similar problems?  Solutions?  Feel free to contact me by email
or phone, see my signature.


Here's a short example program with benchmark results:

-------------------------- 8< cut here  >8 ----------------------------------

#include <stdio.h>
#include <math.h>
/* 
	This sample program demonstrates problems with the 68040
	cpu.  Here are benchmarks for the same program, run on 
	(1) A 68030 diskless HP9000/400t, 8 Mb RAM, served by an
	HP9000/835 disk server,
	(2) A 68040 HP9000/425t, with 16 Mb RAM, internal 200 Mb and
	external 330 Mb disks.

	TIME:		(1) 68030		(2) 68040

	real		1m 16.42 s		57m 11.20 s
	user		1m  3.96 s		 0m 28.46 s
	system       	0m  2.46 s		45m 41.26 s
*/
#define NVALS 50000
void main (void)
{
  FILE *gp, *xp, *pp;
  double *indvar, *depvar, *coef, *yest, *resid, *coefsig;
  double r, rsq, see;
  char error;
  int i;

  gp = fopen ("first.out", "w");
  xp = fopen ("second.out", "w");
  pp = fopen ("third.out", "w");

  indvar  = (double *) malloc (NVALS * sizeof (double));
  depvar  = (double *) malloc (NVALS * sizeof (double));
  yest    = (double *) malloc (NVALS * sizeof (double));
  resid   = (double *) malloc (NVALS * sizeof (double));

  for (i = 0; i < NVALS; i++) {
      resid[i] += 1.0;
      yest[i] += 1.0;
      depvar[i] += 1.0;
      indvar[i] += 1.0;
   }
   printf("Ready to output stuff\n");
   /*  The program reaches this stage instantly; all the time-wasting
   takes place below: */
  for (i = 0; i < NVALS; i++) {
      fprintf (gp, "%19.12lf   %19.12lf   %19.12lf   %19.12lf\n",
	       indvar[i], depvar[i], yest[i], resid[i]);
      fprintf (xp, "%19.12lf   %19.12lf\n", indvar[i], resid[i]);
      fprintf (pp, "%19.12lf   %19.12f\n", indvar[i], yest[i]);
   }
}

-------------------------- 8< cut here  >8 ----------------------------------
--

Larry Gritz                                   lg@galileo.usno.navy.mil
US Naval Observatory                          phone: 202-653-1034
Washington, DC 20392-5100                     also: gritz@seas.gwu.edu