I wonder why CPU vendors stopped producing CPU with frequencies above 3.0 - 3.6 Ghz and switched to using multi-core CPUs?
What was the reason behind this step? Was there a physical constraint or the new approach came up being more feasible?
If you keep raising the clock, eventually you will have power consumption/temperature problems (you probably remember Pentium 4 CPUs which ran fast and hot). You can work around those, of course, but then your cooling system becomes more expensive.
Thus, multi-core (and other approaches, like improving the CPU architecture/organization - so much that comparing CPUs of different families/manufacturers is useless) were born.
Moreover, modern software is multithreaded and will benefit from multicore more than it does benefit from faster clocks.
There are a number of related factors at work. For one thing, main memories have really lagged behind CPU speeds; if hypothetically one were running a single core at 50GHZ and it had to wait 10ns for a value to be fetched from RAM [quite fast, actually], would forfeit an opportunity to do 500 clock cycles' worth of useful work. By contrast, if one had 10 cores which ran at 2GHz each, then such a main-memory fetch would only forfeit 20 clock cycles' worth of work.
Another factor is that CPU speeds are to some measure limited by the ability to get current into a chip and heat out. Making a core run twice as fast would require more than double the current and produce more than double the heat. If using two cores will allow one to do as much work as could be done with one core running twice as fast, it makes more sense to use two cores.
Incidentally, one place where the interaction of hardware and software needs to be improved, IMHO, is in establishing when it's important for code running in one core to be able to see things written into memory by code running in another. Some architectures assume that anything written into memory by any processor should be seen as soon as possible by any other processor that tries to read that location; others require code that wants the most recent thing written to memory to explicitly request that or risk getting "stale data". It's very difficult to make hardware for the former style run as quickly as hardware for the latter style, and the difficulty increases with the number of CPU cores, but it's very difficult to make software for the latter style which is efficient but doesn't occasionally malfunction under circumstances which are essentially impossible to track down. I'd like to see hardware and software support a hybrid approach, with e.g. four groups of four cores each, and a guarantee that all the cores within each group will "see" the same memory, relaxed assurances for cores in different groups, and a default CPU assignment algorithm that would assure that code for any particular application domain would only be run on groups of processors that saw the same memory. In cases where there were four or more separate application domains which each had their own independent work to do, this would allow the cores to be run faster than would be possible if all 16 had to share the same memory image.
As the other answers mention heat. But also the speed of light is a limiting factor.
http://www.google.co.uk/search?q=3+ghz%2F+speed+of+light
Assuming the electrons travel at the speed of light at 3ghz the signal can make it 10cms before the next clock tick
the signal can make it 10cms before the next clock tick
, isn't there an error?
\$\endgroup\$
Commented
Nov 24, 2013 at 22:43
3 ghz / speed of light
= 0.1m = 10cm so at 3ghz the signal has only had the time to travel 10 cms before the signal is changed
\$\endgroup\$
Was there a physical constraint
Yes, heat.. \$\endgroup\$