Date: Tue, 25 Apr 2006 09:59:20 -0400 From: Bill Moran <wmoran@collaborativefusion.com> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-questions@freebsd.org, derek@computinginnovations.com Subject: Re: Purchasing the correct hardware: dual-core intel? Big cache? Message-ID: <20060425095920.a8342390.wmoran@collaborativefusion.com> In-Reply-To: <444E28A5.3010902@mac.com> References: <20060424154617.9dc28c94.wmoran@potentialtech.com> <6.0.0.22.2.20060424175443.02927f48@mail.computinginnovations.com> <20060425084752.2453c0f1.wmoran@collaborativefusion.com> <6.0.0.22.2.20060425075227.028aea10@mail.computinginnovations.com> <20060425092526.6fe5efa6.wmoran@collaborativefusion.com> <444E28A5.3010902@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Apr 2006 09:48:21 -0400 Chuck Swiger <cswiger@mac.com> wrote: > Bill Moran wrote: > [ ... ] > >> If you use well optimized applications, you see the larger performance > >> gain. Poor optimization causes a CPU to chug along, flushing the CPU cache > >> often, and slowing things down considerably. > > > > I know. That's why I'm so desperately trying to find a way to determine > > how often the cache is being invalidated - so I can determine whether > > larger cache sizes (such as 8M) are worthwhile. > > Guys, you're confusing two things: > "flushing the pipeline" vs. "L2 cache hit ratio". > > The former happens when branch prediction/speculative execution goes awry and > requires the CPU to clear the pipeline of partially-executed instructions and > backtrack to follow the other path. It is related to optimization quality of > compilers, but is not related at all to how big your L2 cache is. > > The size of your L2 cache affects how much data is more local to the CPU than > main memory, and increasing it will improve the L2 cache hit ratio, or, > equivalently, reduce L2 cache misses. This is affected by some specific > compiler optimizations (cf "loop unrolling"), but tends to reflect the specifics > of the workload and how much multitasking of different programs you do more than > the compiler. Thanks, Chuck. What I'm looking for is a way to measure this on the current machines we're using so I can make a prediction as to whether larger cache sizes will improve performance. What I'm looking for is some sort of counter or the like that I can use to tell what my current L2 cache hit ratio _is_, so I can intelligently speculate as to whether another 6M of cache is worth the outrageous price. -- Bill Moran Collaborative Fusion Inc. **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060425095920.a8342390.wmoran>