HP-720 vs IBM-320 vs Sparc2

[III]

Immediate disclaimer. I'm an expert in nothing, just a user
who had a chance to demo an HP-720 for 10 days and had a
chance to compare it to our IBM-320 and SUN Sparc2.
These are just my general impressions and if I say something is so,
and it isn't, then it is just my ignorance about HP systems.
We only had the machine for a week and we had no hardcopy documentation.
I'd never touched an HP until last week- but I have worked on
a variety of SUN's, IBM's, STARDENTS, SGI's, GOULD's etc. Also
bear in mind that I do far more FORTRAN than C. Some of these
comments will be old hat for HP old timers and maybe of interest
to IBM-320 or Sparc2 users.

HP Hardware description:
HP-720, 32 megabytes,  19" color, 2*210 megabytes internal,
1*640 meg. external and a 4mm DAT drive running HP-UX 8.0

First impression is what you would expect -the machine is fast!
There is no doubt that it is a hot box. However, as a user I
want a box that is easy to use. I want a machine that can make ME
more productive and not just rack up impressive SPECmarks.
The cost of the man hours involved in many projects often easily
exceeds the hardware costs involved (when talking about current
workstations).

MISC Nice features:
    1. It is fast what more can say. If it core dumps, it
       core dumps fast! -and we saw plenty.

    2. The HP menu driven system administrator, "SAM" seems to
       be quite good and much easier to use than the IBM
       equivalent "SMIT" which I found just to get in the way
       more times than to be helpful. It took very little time
       (<0.5 hrs) to get it integrated into our network of
       SUN's, IBM, and printers. I guess you could say it
       "plays well with others"

    3. monitor- The refresh rate is much nicer than the IBM's
       and easier on the eyes under fluororescent light.
       The colors didn't seem as "saturated" as they are on our IBM.
       The monitor doesn't have the huge "footprint" of the IBM either.

    4. The HP's X11 graphics is fast. Noticeably faster than an IBM-320's
       and somewhat better than a Sparc-2 and the HP X11 is release 4
       and the MOTIF1.1 (the IBM X11 is release 3 and MOTIF1.0 and we
       run MOTIF1.1.1 on our SUNS)

    5. HP-VUE 2.0  -I liked it. The workspace concept is good. I was
       also able to blow it away and get my own X environment up easily.
       The IBM Desktop manager thing is very poor in comparison.

MISC Bad features:

   1. keyboard- had a nice "touch," but the ESC and shift keys are
      just too small. Hopefully they will offer it with other keyboards.

   2. I'm disappointed that HP doesn't support an 8mm tape drive (EXABYTE) on
      the 720. It appears that they have decided that the four formats
      they will support will be: CD-ROM, 4mm DAT, 1/2 inch and HP 1/4 inch.
      Our HP rep. said of course I could write my own SCSI driver for an 8mm
      (and I'm sure somebody will) but I don't want to spend my time doing what 
      I perceive to be their job. I want to spend my time being productive
      developing code in my field. 

   3. I was also disappointed that I couldn't get a chance to demo the
      Interface Architect for producing MOTIF applications.
      Our representative said he couldn't find it for a 720 (?).
      If not hopefully it will be available soon.

Of course its easier to pick nits than to say nice things
because it is the nits that will irritate you into
non-productivity. Plus it is easy to take for granted
all the good things. You get spoiled quickly.
Hopefully some of these things will be fixed in upcoming releases.

NITS:
A) vi
   1.vi does not automatically resize the text when
     the window is resized (the IBM does, SUN doesn't).
     you have to get out and do an eval resize.

   2. vi had lots of trouble with files containing a large
      number of lines even if they contained little data.
      For example a 1 meg. file consisting of 500,000 lines
      (a single X) on each line yielded:

OUT OF MEMORY SAVING LINES FOR UNDO - TRY USING E
     (Guess it want me to use ed huh?) An 8 Meg. byte SUN 3/50
      had no trouble with this file.

   3. Some larger files (>20 meg.) but with fewer lines (about 200k)
      would seg. fault  and core dump vi.

   4. While editing a 250,000 line file, I did a :1,100000 wr hunk1
      Upon examination the resulting file hunk1 was scrozzled.
      I consider this undesirable.

We are mainly a FORTRAN shop here, so the FORTRAN development tools
are very important to use (the compiler, the debugger, fsplit etc.)

B) fsplit - The fsplit is execptionally primitive.

   1. does not have a -e option for splitting out individual routines

   2. splits the files out into file names with capital letters (FOO.f)
      (reminds me of the ETA10-P* at Purdue).

   3. does not  handle duplicate sub-program names.
      I had a 100,000 line file FOO.f which had subroutine in it called FOO
      and when I did  %fsplit -f FOO.f, when it came to the subroutine
      called FOO it just overwrote the master file FOO.f and quit.
      I had to retrieve my complete source from a backup.

C) FORTRAN
   1. First off the FORTRAN compiler is gratifyingly fast (which is good
      for FORTRAN code developers). We were seeing about
      30,000 lines/cpu minute (no optimization)  on large monolithic
      sources (without comment cards).

   2. Porting relatively clean f77 code posed no real problems.

   3. Standard error is on unit 7 instead on unit 0.
      No real problem unless your application was trying to use unit 7
      for something else. I guess this is historical HP (?)

   4. Symbolic debugger- The symbolic debugger adb seemed to be powerful,
      but I was REALLY discouraged because the syntax is so much different 
      from the dbx on most other UN*X boxes and the window driven part is 
      not exactly "point and click." This is really important to us.
      Plus you don't get the debugger with the FORTRAN compiler, you
      have to get the C-developer's package. In this respect the HP does
      not seem to be a good platform for FORTRAN development. In this area
      the IBM debugger seems to particularly good (better than SUN's which
      doesn't have return command and often gets confused with " too many
      levels" just when you're getting down to the interesting part of the
      code).

   5. The +T option of f77 is nice in that it will provide a trace back for
      many exceptions and range errors (NaN generators). You can't
      currently do this on the IBM-320. However, the traceback doesn't
      provide line numbers but merely routine names and addresses. This is
      something that STARDENT did well.

   6. The compiler on +O2 level would warn about use of unitialized
      variables. This is a nice feature, since unitialized variables
      often screw with optimizers assigning variables to registers.

   7.  The fortran compiler (quietly sometimes) links into the C library.
       Sometimes it warns you, e.g.

Warning on line 58354 of testcomp.f: Wrong number of args to intrinsic free

       Last time I looked, free was not an f77 intrinsic. This meant that
       I had to go in and add external statements so it would use MY
       subroutine free. O.K. I know that if trying to write good, 
       PORTABLE FORTRAN  code, one should always declare one's function 
       to be external, for just this circumstance, but there is a lot of 
       code out there where people don't.

   8.  Lack of FORTRAN callable flush and loc functions. I want to be
       able to flush my own buffers, and I want to be able to implement
       my own memory management routines w/o C calls.

   9.  When trying to compile a large (268504 lines without comments)
       FORTRAN application  monolithically (and w/o opt.) I ran into
       several problems: The compiler seemed to be in real trouble
       over 150,000 lines and gave seg. faults several times:

f77: Signal 11 (segmentation violation) while compiling all.f

and several times just bailed out on me with:

f77: compiler error.

      After fsplitt'ing this puppy I then ran into trouble with the
      csh file globbing.

         f77 *.f

      would only work with up to 104 files. Any more and it just gave up.

      Well I had about 2100 files and then I couldn't cat' them back together.

duncan:/disc1/rhodesii/ALL>cat*.f > all &
produces:
duncan:/disc1/rhodesii/ALL>Arguments too long.
[1]   Exit 1               cat *.f > all

      To be fair the Sparc2 couldn't do this either, but the IBM-320 did it
      just fine. The IBM FORTRAN compiler (xlf) also was the only one of
      the 3 machines that could eat the entire monolithic source. The Sparc2
      started seg. faulting when the -Nx option got up to 3000. The HP and the
      IBM seem to increase their table sizes "on the fly" and make another
      go at it instead of just bailing out like the SUN's.

E) MISC. UNIX
    1. Both df and ps are very SYS-V'ish so ps doesn't have the normal
       plethora of Berkley options. They do provide a bdf which is o.k.
       if you rewite your scripts and top and monitor commands can
       kinda substitute for ps but neither of which are as
       satisfying as having a clear consise ps (IMHO).

    2. For symbolic links ln requires two args instead of
       the 2nd being optional. i.e. you can't just ln -s ../foo
       but must use ln -s ../foo foo
       (I hate extra typing).

    3. make can not handle a makefile with over 500 targets.

    4. Couldn't find a ulimit,limit or unlimit command in csh.
       some of our appplications would only run under the native ksh
       (after bailing out complaining about system limits when
        run under csh).

The only C-applications I took over were PERL3.0, less, and fsplit,
and my own X applications. No real problem here after finding
where the X11 libraries and include files were.

The interactive on the HP seemed to suffer more when large jobs 
were running in the background than on the IBM (long repsonse
time between returns, unable to get its attention to rlogin etc.).

The HP software support seemed to be much better than IBM's
(which has been a nightmare for us since day 1).
I was able to talk to somebody who knew what was going on
right away. It takes hours with the IBM support just to get
a straight answer. 

However, overall the HP-UNIX seemed a little crude compared to 
the IBM AIX and the SUNOS as well. This surprised me since I 
thought after acquiring Apollo that HP acquired a few years worth 
of UNIX experience as well and that it would be more robust.

I have found that most of the changes in IBM's AIX really are 
improvements in that they add extra functionality or make 
something easier (except for things like maybe calling mt, tctl and 
f77 (even if it's not BSD f77) xlf. I like the journaled file
system on the IBM much better than the SYS-V file system.
Additionally the IBM seemed more comfortable handling large files, 
large numbers of files, and big jobs than either the HP or the SUN.

I am glad to see that HP sells the 720 with a minimum of 16 Meg.
We bought our IBM with 16 and after several frustrating months
increased it to 32 Meg (3rd party). If IBM had been upfront about
the memory requirements before hand we would have just gotten 32
Meg to start with and be done with it. Anyway IBM sells the 320
in an 8 Meg. configuration which I can't believe even has room
for the operating system :-)

Well, you can quote whetstones/dhrystones/livermore loops all you want,
but as a user the bottom line (all I really care about) is how
fast can it run MY application. Here is a small sample of what I saw:

         CPU hrs
HP-720     2.7  f77 +O2 +Obb1200 (32 MEG. RAM)
IBM-320    4.8  xlf -qopt=2 -NQ30000 -NT40000 (AIX 3.1.5/xlf 2.1) (32 MEG. RAM)
Sparc2     6.2  f77 -fast -O3 -Nx1500 (SUNOS 4.1)(SUNOS 4.1/f77 1.4) (16 MEG. RAM)

The code in this case was SIMULATE-3, a 3D, nodal, multigroup
diffusion theory nuclear fuel cycle analysis code. This was about
the max. gain that we saw. Realistically (in our applications),
the HP-720 was about 2-2.3 times faster than the Sparc2 and about
1.5 to 1.8 times faster than the IBM-320.

As far as the Livermore loops went we saw an AVERAGE of about
10.8 MFLOPS for the HP, 7.1 for the IBM and 5.5 for the Sparc2
and repsective Whetstones ratings of 35461, 19305, 17513 single
precsion kips, and 31348, 20864, and 15244 double precision kips.
Actually for our applications everything pretty much scales
as the average MFLOPS.

Regardless of the nits expressed above, overall, I was very 
impressed with the 720 and since we have a professor
and several summer students visiting us soon and we need another machine,
we probably will go ahead and get an HP-720 (we were told we could get
one in eight weeks). It didn't crash once during the 10 days that we had it
(our IBM used to panic regularly in its early days). We liked its 
speed/throughput and it is always nice to have other compilers around, 
but there are many small things that they could do to help make 
me (the user) more productive.

-joel
-- 
-----------
Joel Rhodes                 *   rhodesii at othello.studsvik.com
Studsvik of America,INC.    *   uunet!idaho!othello!rhodesii
Nuclear Code Development    *   Idaho Falls,ID. USA  ph 208-522-8443