Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!sol.ctr.columbia.edu!caen!uflorida!bikini!bb From: bb@reef.cis.ufl.edu (Brian Bartholomew) Newsgroups: comp.sys.hp Subject: Re: HP9000 performance Message-ID: Date: 5 Feb 91 00:17:57 GMT References: <13092@sunquest.UUCP> <7370295@hpfcso.HP.COM> Sender: news@uflorida.cis.ufl.EDU Organization: /cis/lightning0/bb/.organization Lines: 100 In-reply-to: mjs@hpfcso.HP.COM's message of 31 Jan 91 17:43:19 GMT ">" = (marc@hpmonk.fc.hp.com) Marc Sabatella "%" = terry@venus.sunquest.com (Terry R. Friedrichsen) "&" = thoth@reef.cis.ufl.edu (Rob Forsman) "$" = bb@math.ufl.edu (Brian Bartholomew) ----- $ 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. > This is not true. They are "upwards compatible" only. For several > releases now the 300 compilers generate 68020/68030 specific code. > The opcode improvements on the 68040 are minimal (move16 primarily) so > we do not currently emit 68040-specific code. However, we have tuned > the compilers to generate code to best take advantage of the 68040 - > instruction scheduling based on the 68040 pipeline architecture, > avoiding address modes that are unduly expensive on the 68040, etc. > Bottom line: current (ie, 7.40) compilers generate code to take full > advantage of the 68020/68030 opcodes, and are tuned to emit the best > code possible for the 68040. It sounds like you are agreeing with my statement. You aren't using '040 or '030 opcode enhancements. You are placing opcodes in a clever way that cooperates with the '040 cache, and that hopefully doesn't cost too much on '020s and '030s. You are "avoiding address modes that are unduly expensive on the 68040" by virtue of not using any of the '040 opcode features at all. Whether this approach is signifigantly less efficient than one that eschews binary compatibility in favor of optomization is a matter for benchmarks. I made the comment in the first place because my intuition suggests there is a signifigant performance hit from this approach. The above statement, that all 200, 300, and 400 binaries are identical, is corroborated by an invocation of "file /bin/*", which describes all the executables as written for the "s200 ..." architecture. I ran this on a 300 series machine, that returns "HP-UX kzin 7.0 B 9000/375 kzin" for "uname -a". ----- $ 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). > Starting with 7.0, most of the code is indeed just a recompile, with > obvious exception like code generators and some kernel code. Then how come things like the disk partitioning work quite differently? I have gotten the impression that there are a lot more more differences between the 400s and 800s than I know of. ----- > A more diplomatic response: it is not BSD, so you may find switching > awkward at first. If you are more used to System V, you should find > it quite natural. Fair enough. In our environment, a close compatibility with the machines that the writers of free software are using, is a very big plus. ----- > TCP/IP One major irritant is that the TCP/IP implementation is based upon the HP Network Services code, NS. This ties you to a lot of NS limitations, like 8-character hostnames, and the requirement to run NS daemons if you want to run TCP/IP. ----- % X11R4 from MIT > Try defining "MALLOC_0_RETURNS_NULL" when building X11R4. MIT assumes > malloc(0) returns the current breakpoint, but not all malloc's behave > this way, so an #ifdef was added. Oops. Most likely this is strictly our mistake. ----- > You would, of course, have no trouble debugging if you used HP's C > compiler and the supplied debugger xdb. Again, this is more a question of the environment we are used to. I haven't used xdb, so I won't speak ill of it. -- "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