From owner-freebsd-hackers Mon Aug 4 17:48:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09111 for hackers-outgoing; Mon, 4 Aug 1997 17:48:40 -0700 (PDT) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA09100; Mon, 4 Aug 1997 17:48:37 -0700 (PDT) Received: from moth.us.dell.com (moth.us.dell.com [143.166.169.152]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id TAA06920; Mon, 4 Aug 1997 19:48:05 -0500 Message-Id: <3.0.2.32.19970804125520.0070d730@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Mon, 04 Aug 1997 12:55:20 -0500 To: "Jonathan M. Bresler" From: Tony Overfield Subject: Re: Pentium II? Cc: cjs@portal.ca, freebsd@atipa.com, tom@sdf.com, hackers@FreeBSD.ORG In-Reply-To: <199708031631.JAA01116@hub.freebsd.org> References: <3.0.2.32.19970803041915.006a69e4@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 09:31 AM 8/3/97 -0700, Jonathan M. Bresler wrote: >Tony Overfield wrote: >> I think many of the benchmarks indicate this. The benchmarks show, when >> run at the same clock frequency, that the Pentium II runs at speeds >> comparable to the Pentium Pro, even though the L2 cache is running at >> half-speed. Many folks had claimed that the Pentium II would be much >> slower because of the half-speed L2 cache. > > oh? what is the size of your dataset? what is the data access > pattern? without specifing these two items, i cant tell how > your are using L1 and L2 cache. Of course, that's obvious. But my point is that a larger L1 cache makes the Pentium II faster than it would have been otherwise, since it partly offsets the slower L2 cache. In many real-world situations, the dataset size and access patterns constantly change. A bigger L1 cache only wins whenever the L1 cache hit-rate is improved strictly because of its size. To believe that such a sitiuation never arises seems to me to be a losing position to take. > what we need is a benchmark that has a fixed data access pattern > and known data set size. better yet would be one that starts with > a very small data set and grows the data set till the computer starts > using disk. a graph of the results would show the speed of the > machine accross all its memory regimes. > > http://www.scl.ameslab.gov/scl/HINT/HINT.html Thanks for the pointer. The effect I'm describing seems to be visible in their data, especially if you select the "(double)" data. - Tony