On Thursday, January 12, 2012 03:27 PM Haro de Grauw wrote:
Hi folks,
I notice the trend in desktop CPUs is that clock speeds have been steady for some time at 2...4GHz obviously depending on price, while the number of cores is on the increase, current offerings running from one to eight cores. I always thought that more cores is good for doing lots of things simultaneously, but not necessarily for single CPU-intensive tasks, as these are often not able to run in multiple threads/cores at the same time. I'm obviously not an expert, so do correct me if I'm wrong.
To check this, on a dual-core system, I tried looking at ksysguard (System Monitor), and as expected I see that a number of CPU-intensive tasks run up to 49% CPU usage (example: file compression with ark). Surprisingly, however, when I switch to the 'System Load' tab in ksysguard, the graph clearly shows CPU1 and CPU2 both running at or near maximum (100%), even though the CPU usage of all processes adds up to much less (say, 49% for ark, and not more than 10% for everything else).
Two questions:
1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed? (I'm aware of the 'benchmark'-style comparisons around the Internet, but it's their ecological validity I'm curious about.)
2) Is what I see a possible bug in ksysguard, or is there something I'm not understanding here?
Cheers!
Haro
There are of course other forums which are focused on hardware performance, that would be your best source of information. IMO the question is really over-simplified. There are a number of inter-related issues to be considered, each of which has its own specifics. Here fwiw are a few generalizations: The first is your use model. A quick look at a cross-section of benchmarks will show how a processor performs differently under types of loads. So depending on the function being performed and how a particular application is designed, that may favor clock speed over cores or vice versa, or neither. Another consideration is the architecture of the processor. Beyond clock & cores there are factors such as L3 cache and the bandwidth of the memory controller. The RAM and the chipset can also be factors. And then yet again another consideration are other system components which may gate performance more than the cpu. Some obvious examples are gaming (GPU), database (storage), or the network (switch, etc.). There is the general rule that a clock >3GHz typically is only utilized in cpu intensive functions, e.g., video processing or financials. Additional cores are useful with multi-tasking, although only a second core doesn't buy all that much; IMO with today's cpu's a quad has better payback. But the biggest bump with cores comes from multi-threaded programs which are designed to utilize the cores. Still, when 3 of 6 cores are pegged at 100%, don't expect the other cores to be able to do much else because probably the memory controller and/or bus will be saturated. So in the end it all comes down to what you do with the machine, what you can afford, and how much homework you're willing to do. To that I'll just add that a much more powerful processor (and RAM) may be affordable if you architect and build your own machine; sometimes you can economize on other components, and you can re-use many components across several upgrades. I've done this with my workstation for years and I've spent less than buying replacement PC's while always having maximum performance. Re Ksysguard: The CPU% you see on the Process Table is the cumulative for the process across the cpu, so if 2 cores are being used at 25% it will show on the Table as 50%. The System Load sheet will show each CPU load separately. That said, there is load on the CPU which shows on the Load sheet but which does not show on the Process Table. I have no idea why; it is annoying. I imagine all of this is just being read from what is being written to /proc, so I don't know if the issue is with Ksysguard (although IIRC I've seen the same phenomena in htop & top) or the kernel or just the way that it is. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org