Date: Mon, 29 Sep 1997 10:05:02 -0500 (CDT) From: Tony Kimball <Anthony.Kimball@East.Sun.COM> To: tom@sdf.com Cc: Anthony.Kimball@East.Sun.COM, michaelv@MindBender.serv.net, toj@gorilla.net, freebsd-hardware@freefall.freebsd.org Subject: Re: supermicro p6sns/p6sas Message-ID: <199709291505.KAA25150@compound.east.sun.com> References: <199709282221.RAA23164@compound.east.sun.com> <Pine.BSF.3.95q.970928194724.21363A-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Tom on Sun, 28 September: : > The supporting argument is insufficient for the conclusion. AMD and : > Cyrix are actively engaged in providing alternate paths to cache. One : > proposed solution is to make a low-profile Socket 7 module with an : > on-board cache controller, making the Socket 7 interface effectively : > a point-to-point bus -- analogous to Slot 1. : : None of these methods exist yet. Compare the MediaGX. "Proposed" in the sense of proposed for industry standardization. : Is CPU performance measured in months now? :) I was not thinking about CPUs, but CPU development paths. To my mind, the performance comparison of different development paths (application-based, rather than feature-based -- so this principle can apply equally well to comparing Alpha to clone-86 or name-your-poison) is best done, not in terms of raw performance of the best exemplar at any given moment, but rather, by how long a given performance point of one development path (i.e. performance of best exemplar, or perhaps best exemplar at a given cost-benefit-point, depending on the planning purposes of the metric) lags behind the equivalent point in the development cycle of another path. This approach is much more useful for purposes of technology management (e.g. in an enterprise) than is raw benchmarking -- and I see no reason why I should not apply the same rationale to my personal purchase planning, on a smaller scale. But for some people/situations, all that matters is what runs make world fastest within your budget, or whatever. We can all read the benchmarks, eh? : I'm little dubious about how well AMD : can make it work. K6, due to bugs, was unable to run FreeBSD reliably up : until a few weeks ago (see archives about which stepping are known to : work, and which are not). And we all know that Intel has had no major Pentium or PPro bugs? (BIG smiley face on that one.) Frankly I don't see any reasonable argument to the effect that AMD or Cyrix are less technically competent than Intel -- quite the contrary, given track records (and the fact that the AMD/Cyrix task is much more difficult than the Intel task). : Also, you can use socket 8 processors in a slot 1 with an adapter. Where can I learn about this?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709291505.KAA25150>