Date: Thu, 10 Apr 1997 10:29:33 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: Anthony.Kimball@East.Sun.COM Cc: smp@csn.net, hardware@FreeBSD.ORG Subject: Re: Pentuim or Pentuim Pro ? Message-ID: <199704100059.KAA28539@genesis.atrad.adelaide.edu.au> In-Reply-To: <199704091826.NAA02162@compound.east.sun.com> from Tony Kimball at "Apr 9, 97 01:26:53 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Kimball stands accused of saying: > 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. Hmm, we don't see this. I would call anything that deals with the output of a digitiser system with 64M of memory "data-intensive", and the SDRAM stick we borrowed did nothing at all for our systems. Currently, we're using HX boards because we want to be able to handle a full dataset in memory, and because the ones we're buying (Tekram) have onboard SCSI and 512K L2. We would happily have used SDRAM on our lower-end systems if it had helped performance at all. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704100059.KAA28539>