From owner-freebsd-hackers  Mon Jan 22 10:51:19 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA05321
          for hackers-outgoing; Mon, 22 Jan 1996 10:51:19 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA05316
          for <hackers@freebsd.org>; Mon, 22 Jan 1996 10:51:17 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15590; Mon, 22 Jan 1996 11:42:43 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199601221842.LAA15590@phaeton.artisoft.com>
Subject: Re: stanford benchmark/usenix
To: davidg@root.com
Date: Mon, 22 Jan 1996 11:42:43 -0700 (MST)
Cc: lehey.pad@sni.de, hackers@freebsd.org
In-Reply-To: <199601221310.FAA14741@Root.COM> from "David Greenman" at Jan 22, 96 05:10:05 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
Precedence: bulk

> >Yes, I thought of that.  The alterneative of being able to run the
> >versions on all processors rather defeats the advantage: I had thought
> 
>    Not at all. Most of the optimizations that can be made don't use
> CPU-specific instructions. It's all in just organizing the instructions
> a little differently are making some algorithmic changes to take better
> advantage of difference cache quirks.

I agree with David.  It's not use of P5 instructions, it's ordering of
386-on-up instructions in most cases.

So the code will run, but it will run slower on a hardware/code mismatch.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.