Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!uvaarpa!mcnc!decvax!decwrl!hplabs!hpda!hpcupt1!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.sys.hp
Subject: Re: HP825 math 15x SLOWER than 825
Message-ID: <1340009@hpclscu.HP.COM>
Date: 29 Mar 88 19:35:21 GMT
References: <830004@bgphp1.UUCP>
Organization: HP ITG/ISD Computer Language Lab
Lines: 106

> 
>         In a multitasking environment the 825 can be at least
> 
>                      15 TIMES SLOWER
>                      ^^^^^^^^^^^^^^^
>         than a 3 cpu 500!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> NOTES:
> HP9000/500: 6.5 MBytes main memory, 3 floating point CPUs, 65MByte
>             system, 55MByte /tmp disk, 132MByte user disk, 571MByte
>             data disk (Used by virtual memory), HP-UX 5.21.
> 
> HP9000 series 825 (HP Precision Architecture, RISC machine)  16 MBytes of
>             main memory, single 404MByte disk drive.  HP Demo, 3/23/88.
>             HP-UX 1.2 (Also tried it on HP-UX 2.0 pre-release with slightly
>             worse results).
> 
Errr...,

Before posting such stuff, it might have been nice to consult with the
HP support org.

1. On your 500, your swap area and your user data area are on different
   disks, thus leading to less contention on the disk. On your 825 system,
   you used only one disk.

2. Did you compile your benchmark with optimization (-O)? From the makefile
   you attached, obviously not!

3. The 571 meg. disk on your 550 (a 7937, n'est ce pas?) is faster than the
   404 meg disk (a 7935) on the 825.

The first item is especially damaging, since your multitasking system is
obviously very swap-intensive.

Also, each system has one or more things that it does well. In the case of
the 825, what it does very well indeed is cpu-intensive stuff. The
cpu-to-memory bandwidth is good, too, but not on the same scale as the raw cpu
speed. The compilers on the s800, therefore, rely heavily on the optimizer to
take advantage of multiple registers and reduce physical memory usage as much
as possible. Therefore, to get the best performance out of applications on
the 825 , THEY NEED TO BE OPTIMIZED!!!

> 
> Is the 825 really that bad?  Could there be a problem with the 825
> I tested.  The sieve benchmark came out 12 times faster than a
                                          ^^^^^^^^^^^^^^^
> single cpu 500 and all my I/O benchmarks came out very fast.  I
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> think the 825 has a real problem with number crunching.
> 

See, there are no problems with integer arithmetic and I/O (which is memory
mapped). The problems you are having are with floating-point performance.
(The famous MFLOPS number). This is being addressed : the 825 is rated at 0.7
MFLOPS (LINPACK?), and there is now a newer model (the 835) out there with a
much faster floating-point card (> 2 times).

> I HAVE NEVER SEEN SUCH A SOLID MACHINE!
> 
> ************************************************************************
> *                                                                      *
> *  BRING BACK THE 500 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  *
> *                                                                      *
> ************************************************************************
> 

Thanx for the compliment. The 825 is pretty solid, too. Our s800 HP-UX (on
a different CPU) has not had a crash in over 2 years. The only problem we
ever had were a few mysterious swap errors which were traced down to an old,
faulty disk with a bad head.

The 500 had the unfortunate problem of being squeezed from both above (by
the new s800's) and below (by the s300's - 680x0 based boxes). This
positioning problem coupled with the (relatively) soft order situation was
what led to its obsolescence. The continuing effort to maintain and
enhance HP-UX on several radically different architectures was getting a
little difficult, and the resource crunch was much too severe to justify
such an effort.

Maybe if there's enough demand, there would be talk of reviving it, though I
feel that there are other alternatives. It won't be long at all before we
have an alternative machine that has the price of a 550 with much better
performance. In general, reducing the number of disparate machines has the
(overwhelming) benefit of offering customers a much wider range of
performance in the *same* architecture. The hard part that a company faces
in such a situation is choosing which set of customers to hurt: the old loyal
customers who are very happy with what they have, or the prospective new
customers who are looking for a wide range of models to choose from and a 
relatively easy migration path.

Besides  - the s500 HP-UX was sort of an unusual item - its guts are different
from the two major flavors out there (sysV, BSD) while trying valiantly to
present the same interface. Maintaining it was no simple matter of keeping the
guts uptodate across different models (which is what is done for the s300 and
the s800 models), but completely re-implementing each new feature. The file
system would have been most deeply affected by this - it was radically
different from anything in sysV or BSD. The s300/s800 version of HP-UX has an
essentially sysV file system with BSD extensions, and keeping track of industry
standard features like NFS was a simple matter of taking Sun's code and making
relatively minor modifications to fit it into HP-UX. For the s500, it would
have been an implement-from-scratch affair.

Lots of thought went into the decision to scrap the s500. So bear with us..

--scu