Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!hp-pcd!hpfcso!mike
From: mike@hpfcso.HP.COM (Mike McNelly)
Newsgroups: comp.sys.hp
Subject: Re: HP9000 performance
Message-ID: <7370304@hpfcso.HP.COM>
Date: 5 Feb 91 16:47:42 GMT
References: <13092@sunquest.UUCP>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 59


	@">"  =  (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.

Your intuition is wrong.  We've measured performance in as many
different ways as we could and from our tests we've found that
addressing mode balance and pipeline scheduling are far more important
than any new opcodes for overall performance.  Early in the development
cycle for the 68040 products we conducted tests which used the new
opcodes to see if they gave us significant performance improvement.
Nope.  Given that binary compatibility is very desirable across the
Series 300/400 line we decided to put our development efforts instead
into the areas which maintained compatibility and which provided much
greater performance gains on the 68040 architecture.

No compiler I'm aware of uses the full vocabulary of opcodes for the
68040/68030/68020.  Whereas there are specific cases where a particular
opcode can be hand coded to advantage, the far more usual case is that
the compiler-generated preparatory code for a wizzy new opcode
frequently slows down the total program.

The Series 300/400 compilers do not generate optimal code.  Nor does any
compiler I've ever seen on any real machine.  We did put a lot of effort
into improving those areas where a payoff was evident.

Mike McNelly
mike@fc.hp.com