Xref: utzoo comp.sys.hp:9249 comp.unix.aix:5542 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!idaho!rhodesii From: rhodesii@idaho.uucp (III) Newsgroups: comp.sys.hp,comp.unix.aix Subject: HP-720 vs IBM-320 vs Sparc2 Message-ID: <1991Jun6.151807.670@idaho.uucp> Date: 6 Jun 91 15:18:07 GMT Organization: Studsvik of America Lines: 286 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@othello.studsvik.com Studsvik of America,INC. * uunet!idaho!othello!rhodesii Nuclear Code Development * Idaho Falls,ID. USA ph 208-522-8443