3
\$\begingroup\$

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?

\$\endgroup\$
3
  • \$\begingroup\$ Was there a physical constraint Yes, heat.. \$\endgroup\$
    – m.Alin
    Commented Nov 23, 2013 at 19:41
  • \$\begingroup\$ @m.Alin that is what I assumed as well, but could you please elaborate a little bit more on that. Wouldn't a cooling system take care of the heat? And why heat is a problem when frequency increases? \$\endgroup\$ Commented Nov 23, 2013 at 19:47
  • \$\begingroup\$ Related question: electronics.stackexchange.com/questions/76580/… | \$\endgroup\$
    – m.Alin
    Commented Nov 23, 2013 at 19:52

3 Answers 3

4
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ Rather than requiring the OS to schedule threads to guarantee the desired consistency model, one could have a system that supported different models with a "process" scattered across nodes with a naturally weaker consistency requiring hardware to do extra work. Thread allocation then becomes an optimization rather than a requirement for correct operation. Limiting coherence traffic to within a partition is also a known possible optimization. \$\endgroup\$
    – user15426
    Commented Nov 24, 2013 at 21:22
  • \$\begingroup\$ @PaulA.Clayton: Hardware support for "automatic" consistency causes the biggest slowdowns in cases where data has to be moved between different cores' caches, and suitable OS scheduling can improve that. Even when processors never end up accessing the same cache lines, however, the level of "mutual vigilance" necessary to ensure that memory sharing will be handled correctly if/when it happens will impose significant overhead unless ownership of memory among cores is allocated at a level much coarser than a cache line. \$\endgroup\$
    – supercat
    Commented Nov 25, 2013 at 17:02
  • \$\begingroup\$ @PaulA.Clayton: If one specifies that all addresses in a certain range will always [until explicit notice otherwise] be owned by a particular core, and that every individual access by any other core must request the data from the first core's cache, then the first core will be able to access data in that range at "full speed", but everyone else's access will be very slow. Allowing cores to dynamically acquire cache-line ownership will balance out the speed, but if ownership maintained on a cache line basis, fetch of a previously-unowned cache line will require arbitration. \$\endgroup\$
    – supercat
    Commented Nov 25, 2013 at 17:07
-1
\$\begingroup\$

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

\$\endgroup\$
5
  • \$\begingroup\$ didn't get this part the signal can make it 10cms before the next clock tick , isn't there an error? \$\endgroup\$ Commented Nov 24, 2013 at 22:43
  • \$\begingroup\$ 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\$
    – exussum
    Commented Nov 24, 2013 at 23:05
  • \$\begingroup\$ that's not the electrons that would need to move that fast, only the potential. Not quite gonna happen, still. \$\endgroup\$
    – Nicolas D
    Commented Nov 25, 2013 at 18:07
  • \$\begingroup\$ Yes electrons don't move nearly that fast. Also, I think the distance from clk source to any receivers is far less than 10cm. So heat and power limitations kick in way before this is an issue. Still an interesting point though. \$\endgroup\$
    – krb686
    Commented Nov 26, 2013 at 13:16
  • \$\begingroup\$ I agree they cant move as fast as light but light is the upper limit. so the absolute maximum distance away is 10CM \$\endgroup\$
    – exussum
    Commented Nov 26, 2013 at 15:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.