Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!uwm.edu!cs.utexas.edu!samsung!rex!uflorida!bikini!bb From: bb@reef.cis.ufl.edu (Brian Bartholomew) Newsgroups: comp.sys.hp Subject: Re: HP9000 performance Message-ID: Date: 31 Jan 91 05:46:25 GMT References: <13092@sunquest.UUCP> Sender: news@uflorida.cis.ufl.EDU Distribution: usa Organization: /cis/lightning0/bb/.organization Lines: 80 In-reply-to: terry@venus.sunquest.com's message of 29 Jan 91 21:39:39 GMT Key to authorship: ">" = terry@venus.sunquest.com (Terry R. Friedrichsen) "&" = thoth@reef.cis.ufl.edu (Rob Forsman) "$" = bb@math.ufl.edu (Brian Bartholomew) > Some standard benchmark results would help. I'm particularly interested > in the 800-series machines. $ Our site has the most experience with 300 and 400 series, which are $ Motorolla 68K based machines. Note that the 200, 300, and 400 series $ are all binary compatible, which tells me that the HP code is not $ taking advantage of the opcode improvements of the later 68K's. Note $ also that there are signifigant differences between the 400 and the $ 800 Operating Systems; the two OS's are subtly different, and appear $ to be generated by two teams in parallel instead of generated by a $ recompile (a'la Sun 3 and 4). This leaves landmines for people $ switching machines to find. I have grown to think that the 800's were $ designed to be servers, and the 300's clients. There are a few key $ things missing from the 400's, like disk partitioning, specifying an $ arbitrary drive and partition to autoboot from, and so on. > So if someone has some benchmark results (SPEC results would be great), > I'd love to see them. Also I'm interested in any remarks you might have > about the I/O throughput of these machines. > What is the consensus of opinion regarding HP-UX? Good, bad, ugly? How's > the TCP/IP implementation? Does X11R4 run as distributed from MIT? How's > the C compiler? Do they really feel as fast as their MIPS ratings? & HP-UX SUX. Ugly. Painful SysVR2 (not 3, not 4) variant. > TCP/IP & This has a problem with non-blocking output to sockets; this gives at & least one large program (empire, a game) fits. > C & Screwy, arcane compiler flags to adjust STATIC tables in the various & compiler passes. Many programs (perl, X distribution, etc.) will not & compile without fiddling with these switches. $ We have played with compiling BSD source (e.g., "ls") under the $ HP-supplied compiler, and they turn out 30 or 40% bigger than the HP $ executable. I suspect that the compiler supplied is a version of the $ old AT&T portable C compiler; you might have much better luck with the $ spiffy (and non-bundled) HP "fancy C compiler" product. Better yet, $ I'd suggest that you get GNU's gcc - it's free, and you get full $ source. However, it is tough to build with the clunky HP C compiler. > X11R4 from MIT & "Cannot perform realloc". We don't know where this is coming from, we & are still working on it. This basically disables all X toolkit & programs; and is especially painful because (a) HP didn't give us dbx, & and (b) gdb can't find any symbols, even though we compile it -g. > MIPS & Fast. Especially the HP-supplied X server. However, it is a bit & buggy (xtank generates spurious pixels [XCopyArea problem?] and long & XDrawText requests will cause the fonts to effectively "greek". $ This bug usually hits me with long lines in xmh. > Conclusion: &$ Get Suns!!! -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!mathlab.math.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu