From owner-freebsd-hardware  Wed Apr  9 11:27:43 1997
Return-Path: <owner-hardware>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id LAA06379
          for hardware-outgoing; Wed, 9 Apr 1997 11:27:43 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA06372
          for <hardware@freebsd.org>; Wed, 9 Apr 1997 11:27:40 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA01707; Wed, 9 Apr 1997 11:33:45 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
	id OAA22246; Wed, 9 Apr 1997 14:26:43 -0400
Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id OAA05197; Wed, 9 Apr 1997 14:26:44 -0400
Received: (from alk@localhost) by compound.east.sun.com (8.8.5/8.7.3) id NAA02162; Wed, 9 Apr 1997 13:26:53 -0500 (CDT)
Date: Wed, 9 Apr 1997 13:26:53 -0500 (CDT)
Reply-To: Anthony.Kimball@East.Sun.COM
Message-Id: <199704091826.NAA02162@compound.east.sun.com>
From: Tony Kimball <Anthony.Kimball@East.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: smp@csn.net
Cc: hardware@freebsd.org
Subject: Re: Pentuim or Pentuim Pro ? 
References: <199704091535.KAA01745@compound.east.sun.com>
	<199704091755.LAA08240@Ilsa.StevesCafe.com>
X-Face: O9M"E%K;(f-Go/XDxL+pCxI5<W_e*r7B8ojMD.5+qDgOp4/\gTQEgbOoBqf:Vtl*aW:<;9/
	UIVk'U^XhYg+v#r~*X<$Q=_ik@5:%E}pl]9|9|:]WLW8n:fLgg0~cfwWRBQxK/HSG0b1D/gljJC$qp
	b=HDF@+"H<|fXy`w#$8#6A"!F:>*gr[=FN@Y`cl1.Tn
Sender: owner-hardware@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Quoth Steve Passe on Wed, 9 April:

: the numbers I've seen for SDRAM suggest there isn't much gained in REAL WORLD 
: situations.  Can't remember the specifics but do remember thinking at the time
: that I apparently wasn't missing anything..

Yes, but... REAL WORLD is just another way of saying 'my application'.
If you run data-intensive memory-walking codes, typical of scientific
computations, SDRAM is a substantial win.  If you run mostly from
cache or random uncached locations, SDRAM is a wash.  For my own
typical applications, the REAL WORLD performance of SDRAM is
substantially better than FPM/EDO/BEDO.