On Wednesday 19 September 2007 15:53, Aaron Kulkis wrote: > Randall R Schulz wrote: > > On Wednesday 19 September 2007 12:53, JJB wrote: > >> Price for the system is the same with quad core 1.6 or dual core > >> 3.0 ghz, > > > > That's an interesting pair of options. I wonder how to analyze > > one's applications to make the better choice. > > The more cores contending for memory access, the more your system > falls short of theoretical maximum throughput. > > So, go with the high-speed dual core rather than the low-speed > quad-core. Memory contention issues will more than destroy the > theoretical 0.4 GHz*CPU advantage of the quad core.
Not necessarily. Some instruction mixes have a much higher ratio of CPU internal instruction cycles to memory accesses than others. For example, tight inner loops (where all the instructions remain in the level 1 cache) that perform lots of floating-point operations on values that were computed by the immediately preceding instruction (again benefitting from the on-chip cache) will exhibit relatively few memory accesses per clock cycle. In contrast, processing mixes that involve a lot of data movement and relatively little calculation (especially mixes that use few instructions that take multiple clock cycles) will benefit most from fast RAM. There's no one-size-fits-all answer. If you really want to optimize a particular application, you must understand and analyze it carefully. For "general-purpose" applications (not really meaningful without _some_ characterization of the processing mix), there presumably are some kinds of rules of thumb, but I'm not sure what they are. (I know that for the application that absorbs most of my attention these days the dominant factor is definitely RAM speed. I've observed that a 2.0 GHz Core Duo (_not_ Core 2) beats a 3.0 GHz Pentium 4 HT simply because the former has faster memory. In fact, the ratio of the speed of my current project is almost exactly the ratio of the RAM speed between the two systems. It's as if the CPU speed didn't even matter! > ... Randall Schulz -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
