9 ms·

Why have CPUs been limited in frequency to around 3.5Ghz for so many years?

257 points by NARKOZ 15y ago

glimcat 15y ago
Because scaling limits. The stuff we're already getting uses very highly doped silicon. You could go smaller or faster if you could dope it more to keep the field characteristics viable, but more doping would screw up the silicon lattice. "More" also generally means an orders-of-magnitude increase. There are a few alternative processes and materials, but they're costly as all hell and hard to do in bulk.
jacquesm 15y ago
I'm probably in a very small minority but I think that the 'free ride' we got from Moore's law in terms of transistor density leading to an increase in clock frequency has caused us to be locked in to a situation that is very much comparable to the automobile industry and the internal combustion engine. If it weren't for that we'd have had to face the dragons of parallelization much earlier and we would have a programming tradition solidly founded on something other than single threaded execution. Our languages would have likely had parallel primitives and would be able to deal with software development and debugging in a multi-threaded environment in a more graceful way. Having the clock frequency of CPUs double on a fairly regular beat has allowed us to ignore these problems for a very long time and now that we do have to face them we'll have to unlearn a lot of what we take to be un-alterable. I'm not sure about much about the future, the one thing I do know is that it is parallel and if you're stuck on waiting for the clock frequency increases of tomorrow you'll be waiting for a very long time, and possibly forever.
- tezza 15y ago
  I think we would just have run into Amdahl's Law earlier. http://en.wikipedia.org/wiki/Amdahl%27s_law http://en.wikipedia.org/wiki/Amdahl%27s_law . Basically you don't get a free pass for parallelising things. . If 90% of a task is parallelizable then the maximum speedup you can get with infinite cores is 10x
  - larsberg 15y ago
    Indeed, we see this today with our compiler (Manticore). On our 48-core AMD and 30-core Intel boxes, we now routinely have flattening speedup curves due to the small sequential portions of even our supposedly "embarrasingly parallel" benchmarks. Compilers, even icc, are still shockingly bad at making good use of the x86_64 instruction set for sequential code. Part of that, of course, is due to C. But part of it is also our (my) fault as compiler writers because even with fantastic type information and unambiguous language semantics we emit shockingly dumb code.
    - jules 15y ago
      Can you elaborate on x86_64 code generation? (are you referring specifically to the vector instructions?) What do you think are the most promising directions to improve in this area?
      - larsberg 15y ago
        Yes, certainly the vector instructions. There are a few keys issues many C compilers seem to run into today: - Loop unroll identification is really bad. For example, ICC will unroll and turn a single-level loop with a very obvious body into streaming stores if the increment is "i++" but not if it is the constant "i+=1". - The register allocation problem has some subtelties. Many of the SSE registers overlap the name of the multiple packed-value register with those of the individual ones (e.g. "AX = lower 16 of EAX"), so knowing that you want four numbers to be in the right place without additional moves means a little bit more thinking. But, there's also very little control-flow analysis done or global program analysis done except for some basic link-time code generation and profile-guided optimization. There's a lot you can do (e.g. cross-module inlining; monomorphizing to remove uniform representation; dramatic representation changes of datatypes), though admittedly some of it requires a more static language with some additional semantic guarantees.
  - jacquesm 15y ago
    You're right, there is no free pass. Let me give you one example of how the wrong habits have become embedded in how we think about programming because of the serial nature of former (and most current) architectures: One of the most elementary constructs that we use is the loop. Add four numbers: set some variable to 0, add in the first, the second, the third and finally the fourth. Return the value to the caller. The example is short because otherwise it would be large, repetitive text. But you can imagine easily what it would look like if you had to add 100 numbers in this way, and 'adding numbers' is just a very dumb stand-in for a more complicated reduce operation. That 'section' could be called critical and you'd be stuck at not being able to optimize that any further. But on a parallel architecture that worked seamlessly with some programming language what could be happening under the hood is (first+second) added to (third+fourth). You can expand that to any length list and the time taken would be less than what you'd expect based on the trivial sequential example. Right now you'd have to code that up manually, and you'd have to start two 'threads' or some other high level parallel construct in order to get the work done. As far as I know there is no hardware, compiler, operating system or other architectural component that you could use to parallelize at this level. The bottle-neck is the overhead of setting things up , which should be negligible with respect to the work done. So parallelism would have to be built in to the fabric of the underlying hardware with extremely low overhead from the language/programmers point of view in order to be able to use it in situations like the one sketched above. Those non-parallelizable(sp?) segments might end up a lot shorter once you're able to invoke parallel constructs at that lower level.
- nknight 15y ago
  Not sure why you think you're expressing a minority opinion, you're stating generally accepted fact. We hit the soft limit years ago, that's why Intel finally dumped the Pentium 4, they realized they couldn't make it scale. Everything since has been about finding ways to do more with fewer cycles, and more research and education on parallelization at all levels (from on-die branch prediction up to google-scale distributed systems). I don't know of anyone who disputes this in principle.
  - repsilat 15y ago
    It's generally accepted fact that "the free ride is over". It's more difficult to argue that we'd be better off if it had happened sooner, that we'd escape more quickly to better global optima if the local optimum we're stuck in wasn't quite so deep. Improvements to the processors we've made by adding more cache, executing instructions out of order, predicting branches better etc are making it more difficult to escape from the conclusion we've reached. To use GP's analogy, there's now a gas station for every suburb and a garage for every house. We know better solutions are possible, but getting from here to there is going to be difficult and expensive, and it could be worse than the status quo for the early adopters in the short term.
  - adambyrtek 15y ago
    You are right, this has been predicted some time ago. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software[1] from 2005 is the seminal essay on this subject. [1] http://www.gotw.ca/publications/concurrency-ddj.htm http://www.gotw.ca/publications/concurrency-ddj.htm
- doyoulikeworms 15y ago
  I don't mean this as a backhanded compliment, but you're in no way in the small minority. You've very eloquently explained what pretty much everyone considers to be the actual situation.
- JoshTriplett 15y ago
  Moore's Law still applies today; the number of transistors continues to double every couple of years. However, the transistors no longer go towards making clock speeds faster; instead, we get more parallel cores, and more impressive instruction sets. And I agree that we've taken too little time to look at parallelism. In particular, our current approaches to concurrency (such as mutual exclusion or transactions) don't actually provide much in the way of useful parallelism; they just serialize bits of the code that access shared data. We don't actually have many good algorithms that allow concurrent access to the same data, just concurrent access to different data. Currently writing my dissertation on exactly this topic: a generalized construction of scalable concurrent data structures, which allows concurrent access to the same data from multiple threads without requiring expensive synchronization instructions.
  - JulianMorrison 15y ago
    Clojure's data structures are rather good for "concurrent access to the same data". References change value, but values don't change. The references are protected by read/write locks but the values in them need no protection once they have been extracted and while they are being used.
- dhughes 15y ago
  Even way back in the mid 90s debated getting a Pentium Pro (two CPU) because I couldn't see how a CPU could keep getting faster. But I think I needed Win NT which was too expensive and I was still new to Linux.
xxcode 15y ago
High(er) Frequency means that you have to run at a higher core voltage (this is, in part, because gate propagation delay is inversely proportional to bias voltage, i.e., the voltage corresponding to a 'high' or 1 bit). You have to decrease the propagation delay so that the clock tick gets everywhere in the processor quickly (one part of the clock doesn't lag the other parts, called clock skew). So in order for things to run faster, you'd have to run it at a higher V(bias). Now that means that there are higher thermal costs (things get hotter) - heat produced is proportion to voltage. So its now mostly a thermal management problem. This is the primary problem in the newer chips. Even though we can pack in more transistors, we can't get signals among them faster without higher V and making it run too hot. Therefore, our solution is to use the extra transistors to create a separate new processor, running with a different clock, so the 'tick' doesn't have to reach all parts of this rather big chip, but just needs to be synchronized intra-core.
- archangel_one 15y ago
  Right, but decreasing the size of the chip means that you effectively can get signals around it faster (because they don't have as far to go) and allows them to be run at lower voltages as well - modern CPUs seem to be generally around 1V, but 10 or 20 years ago they were around 2V, so there is (or has been at least?) a reduction in that over time as well.
- shabble 15y ago
  I'm curious if asynchronous logic will get brought back in as time goes on. Multi-core is essentially desynchronising the individual cores since (iirc) clock generation and distribution is one of the most expensive parts of the processor, in both energy and size. Historically, it lost out because of the added complexity of handshaking/synchroniser logic scattered all over the place, and the mess a mishandled metastable condition propagating through the system could cause. How that we've got transistors to burn, however, and routing is no longer done on large empty floors with crepe tape...
  - copper 15y ago
    Well, Handshake did make an asynchronous ARM core not too long ago, and Achronix has a nice business in async FPGAs, so the idea isn't dead. That said, I'm not sure (though I'd love to be proved wrong) that the idea will really go big again. Synchronous chips are still easier to reason about. By far the most expensive real estate on a typical processor is on-chip RAM, and that really does need a clock. Sure, clock-tree synthesis is complex enough that you may even still be able to start up a company selling a tool for it, but it's still possible for a few reasonably competent engineers to do within some weeks.
neuroelectronic 15y ago
Because we've been designing around electromagnetic interference instead of designing with it. A lot of energy is wasted as heat and this heat has to be managed. Even the name electromagnetic "interference" tells you this. It's a conceptual waste that creates an energy waste. Abstraction will only get you so far when your abstraction is fundamentally flawed.
DiabloD3 15y ago
I wish people would quit asking this question. This is just another case of the Mhz myth. Who cares what the clock speed is if modern CPUs can execute instructions 2-4x faster per clock than they did 30 years ago. Go look at the Bulldozer design, 2 hardware decoder/scheduler engines, 4 integer ALUs, 2 fp ALUs, all per core... A shared L3 cache per socket that is owned by the memory controller and is socket-local to other sockets (ie, all memory controllers conspire to cache system memory efficiently and synchronously know what is cached across all sockets)... And the memory controllers also accept memory requests from ANY core on the Hypertransport bus, no matter which socket, and multi-socket boards commonly have one memory bank per socket, thus 4 sockets of dual channel DDR3-1600 would indeed give 820 gbit/sec of bandwidth that can be accessed (almost) in full by any individual core[1]... The ALUs have execution queues, and any thread (currently 2 per core) can schedule instructions on it to maximize ALU packing... And you can now buy Bulldozers for Socket G34 that have 16 threads/8 cores per socket, and G34 boards usually have 4 sockets. So again, who cares what the mhz is? [1]: A 4 socket setup has 4 or 6 Hypertransport links, on AM3+ and G34+ sockets this would be HTX 3.1 16bit wide links running at 3.2ghz, or 204 gbit/sec per link. On a 4 socket ring, that would be 204 gbit/sec off each neighbor's memory bank, plus another 204 gbit/sec (also the speed of dual channel DDR3-1600) from the local memory bank, thus leading to 612 gbit/sec that could be theoretically saturated by a single core. On a 4 socket full crossbar, it would be the full 820 gbit/sec.
- dchest 15y ago
  Who cares what the clock speed is if modern CPUs can execute instructions 2-4x faster per clock than they did 30 years ago. If you could increase clock speed on these modern processors twofold, would their performance improve?
  - jlouis 15y ago
    Not necessarily. The fact is that you could probably do just exactly that by making the pipeline deeper. But making the pipeline deeper has a price: your control logic becomes much more complex and emptying the pipeline is more expensive. The question is then: does the price you pay become larger than the gain. As this is not happening I have a good guess :) Historically, the Pentium 4 is an example of a Mhz-oriented design. The pipeline was made ridiculously deep. This meant that when you had heavy floating point intensive work, then the Pentium 4 was very very fast. Essentially this was because you could fill up the pipeline in the CPU and you have relatively few jumps in that code. It was just a processing job. On the other hand, the P4 suffered for almost any other task. Even to the point where a more beefy Pentium 3 (Tualatin) could beat it. Intel chose a path which was based on the P3 design for their Pentium-M CPU and that is the design which guided Core, Core 2 Duo, Core i7 and so on. So it is possible, but it is not a given it would lead to faster CPUs. Mhz is but one of the knobs you can turn. The problem we are facing is that all the parallelism we can squeeze out of a sequential program has been done. Modern CPUs dynamically parallelizes what can be run concurrently. But to gain more, now, you need to write programs in a style where they expose more parallelism. Welcome to parallel programming :)
iradik 15y ago
Donald Knuth on multicore (2008): Andrew: Vendors of multicore processors have expressed frustration at the difficulty of moving developers to this model. As a former professor, what thoughts do you have on this transition and how to make it happen? Is it a question of proper tools, such as better native support for concurrency in languages, or of execution frameworks? Or are there other solutions? Donald: I don’t want to duck your question entirely. I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the "Itanium" approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write. Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX.[1] How many programmers do you know who are enthusiastic about these promised machines of the future? I hear almost nothing but grief from software people, although the hardware folks in our department assure me that I’m wrong. I know that important applications for parallelism exist—rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years. Even if I knew enough about such methods to write about them in TAOCP, my time would be largely wasted, because soon there would be little reason for anybody to read those parts. (Similarly, when I prepare the third edition of Volume 3 I plan to rip out much of the material about how to sort on magnetic tapes. That stuff was once one of the hottest topics in the whole software field, but now it largely wastes paper when the book is printed.) The machine I use today has dual processors. I get to use them both only when I’m running two independent jobs at the same time; that’s nice, but it happens only a few minutes every week. If I had four processors, or eight, or more, I still wouldn’t be any better off, considering the kind of work I do—even though I’m using my computer almost every day during most of the day. So why should I be so happy about the future that hardware vendors promise? They think a magic bullet will come along to make multicores speed up my kind of work; I think it’s a pipe dream. (No—that’s the wrong metaphor! "Pipelines" actually work for me, but threads don’t. Maybe the word I want is "bubble.") From the opposite point of view, I do grant that web browsing probably will get better with multicores. I’ve been talking about my technical work, however, not recreation. I also admit that I haven’t got many bright ideas about what I wish hardware designers would provide instead of multicores, now that they’ve begun to hit a wall with respect to sequential computation. (But my MMIX design contains several ideas that would substantially improve the current performance of the kinds of programs that concern me most—at the cost of incompatibility with legacy x86 programs.) Source: http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
JoshTriplett 15y ago
We've gotten very close to physical limits. Quick back-of-the-envelope estimate: if electrons traveled at the speed of light through silicon (they don't), then in 3GHz, an electron could travel .1 meters. In reality, electrons in silicon travel quite a bit slower than that. Net result: electrons can barely cross the diameter of the chip in one cycle, even without gate propagation delays and other factors limiting work done per cycle. So, if you want data from a tiny distance away, such as a local register, you can grab it and do something simple with it in one cycle. If you need data from any further away, forget about it; cache takes longer, another core takes even longer, and memory takes far longer.
- Confusion 15y ago
  Fun fact: electrons in an metallic wire under a potential difference move only in the order of mm/s. See e.g.[1] As electrical signals still travel at about half the speed of light, that seems besides the point. However, electrical signals do not need to span the entire width of a chip in order to have an effect. That is true for your example of accessing memory, but not for the actual calculations happening inside the CPU. On each clock cycle, all transistors are 'fed' by the transistors before it. The state of a transistor only depends on the states of the immediately connecting transistors on the clock cycle before it. That means the signal only has to travel the length of a single transistor on each clock cycle. We could have CPU's working at 3THz and a much larger focus on the difference between CPU-bound and IO-bound tasks. [1] http://amasci.com/miscon/speed.html http://amasci.com/miscon/speed.html
  - jacquesm 15y ago
    The easiest to understand analogy to illustrate this that I've found to date is to imagine a tube full of marbles, push one more marble in on one end and another one will pop out instantly on the other end. As long as the marbles are all the same colour it is as though the marble you pushed in has miraculously teleported to the far end of the tube. It appeared to have moved at the speed of light even though in reality all the marbles have shifted only an amount equal to the diameter of a single marble.
karolist 15y ago
No idea. I have my E8400 still kicking ass at 4.2Ghz on air.
- karolist 15y ago
  Ok, let me explain to the downvoters. As the top comment on reddit currently states, there's no issue with speed of light, the issue is with heating. And there's no "3.5Ghz" limit, stock, mass produced heating solutions limit us. People get all sorts of crazy clock speeds by improving their cooling, mine's on Zalman 9500 fan and has no stability issues to run at 4.2Ghz (stock 3.0Ghz).
its_so_on 15y ago
this is why: http://www.google.com/search?q=c+%2F+3.5+Ghz http://www.google.com/search?q=c+%2F+3.5+Ghz that's a theoretical maximum. you increase Ghz, you have a shorter theoretical maximum length of path electricity can take through your chip. An i7 is not that small. You would have to shrink things further and further to get a smaller chip with shorter paths in it, which is what new fabrication methods have been about. Obviously this is very difficult. Sure, chips could be even faster if they were just a few atoms across, but who would expect you to do meaningful computation in that size, or to be able to manufacture that.
- perokreco 15y ago
  This is completely false. You can read why in the comments above.
kashifr 15y ago
According to the Sandia's Cooler whiter-paper pdf: http://prod.sandia.gov/techlib/access-control.cgi/2010/100258.pdf http://prod.sandia.gov/techlib/access-control.cgi/2010/10025... the limit is due to a "Thermal Brick Wall". Basically due to a lack of progress in heat exchanger technology. I have visualized this "Brick-Wall" as a graph with data from Wikipedia pdf: http://dl.dropbox.com/u/3215373/Thermal-Brick-Wall.pdf http://dl.dropbox.com/u/3215373/Thermal-Brick-Wall.pdf
tibbon 15y ago
So what confuses me is that we've seen tech demos (and overclockers) push CPU speed to 4 to 10ghz. Are those gains so artificially made that they just can't be replicated at scale in the public market? We can get them to go faster, just seemingly not for the public. It was weird to buy my new Macbook Pro and after 3+ years, it was .2ghz slower than my old one. Now of course it has more cores, better instructions, etc... but it was still a weird thing. Apple's done a great job of explaining the benefits of new ones to the consumers - they don't. I'm not being sarcastic. At the end of the 90's (and still largely today for most PC companies) its all about specs. Apple sold what you can do with each computer instead in a good, better, best format. I bet a large amount of computers sold at the Apple store never have the sales associate mention the clock speed.
- beschizza 15y ago
  Perhaps because the gains are typically made with the help of cooling systems too unwieldy and unreliable for mass consumption.
- j-g-faustus 15y ago
  Here's an article describing what it takes to reach those speeds: http://www.tomshardware.com/reviews/5-ghz-project,731.html http://www.tomshardware.com/reviews/5-ghz-project,731.html The article is a few years old, and the clock limits have changed, but the principles of reaching them are the same. As for replicating it at large in the public market, I don't anticipate that liquid nitrogen feeds will be ubiquitous anytime soon :)
  - apaprocki 15y ago
    The top IBM POWER7 CPU is clocked at 5ghz and isn't cooled with liquid nitrogen.
    - j-g-faustus 15y ago
      As I said, it's a few years ago. Today you can get 5 GHz with Sandy Bridge on air (although it might entail testing a few dozen CPUs to find one that can reach that high). But the OP was referring to speeds up to 10 GHz, those still need something special. Here's a current Guiness record, 8.4 GHz using liquid helium: http://www.youtube.com/watch?v=UKN4VMOenNM http://www.youtube.com/watch?v=UKN4VMOenNM Other materials might potentially clock higher, an IBM research prototype chip reached 500GHz: http://news.bbc.co.uk/2/hi/technology/5099584.stm http://news.bbc.co.uk/2/hi/technology/5099584.stm
microarchitect 15y ago
This is a good example of why science isn't a popularity contest. The top voted reply makes some vague noises about vt-scaling and leakage. It then claims that we "don't get a very good "off" if the threshold voltage is too low". This is incorrect. Leakage doesn't degrade the logic values for CMOS-style logic, which is the vast majority of the digital logic in the world. The real issue which the OP may or may have been trying to get at is that leakage power eats into the chip's power budget. Since we'd rather not burn our budget on leakage, we reduce leakage by increasing the threshold voltage. But unfortunately, this comes at the cost of frequency. The other very important issue is that of power-density. There's a famous graph that Shekar Borkar of Intel [1] made showing that if we continued to ignore power dissipation issues like in the past our chips would run ridiculously hot (IOW, they wouldn't work at all because they'd just burn themselves to death). There are also other issues like the fact that your wires start acting like antennas at 5+ GHz and that reliability concerns like electromigration and dielectric breakdown are getting worse with newer technologies. A much more recent and reliable (not to mention highly-cited) reference on scaling and power issues is [2]. [1] I found a copy here: http://www.nanowerk.com/spotlight/id1762_1.jpg http://www.nanowerk.com/spotlight/id1762_1.jpg [2] http://www-vlsi.stanford.edu/papers/mh_iedm_05.pdf http://www-vlsi.stanford.edu/papers/mh_iedm_05.pdf
- mbell 15y ago
  While I agree that power is the primary issue leakage does have a correlation with "degrading the off" value. Specifically the effects of drain induced barrier lowering becomes very significant in the sub-threshold region as the channel length is reduced. This has the effect of both increasing drain current (leakage) and making the transistor more difficult to turn off, that is a larger gate bias is required to turn the transistor off. While "leakage" isn't the cause, you do get leakage and a harder to turn off transistor at the same time, at least for this type of leakage.
  - microarchitect 15y ago
    Hmm. In a CMOS structure with a weakly turned off device, you'd need the effective off resistance to be more than 1/20th of the effective on for the logic value to degrade by roughly 5%. Did we have such leaky transistors for 130nm/90nm when the shift happened? A quick calculation I did with a 90nm model for I have some parameters with vt=0.3, vdd=1.2, subthreshold slope=90mV/decade and dibl coeff=0.1 seems to suggest that leakage would still be < 1/100th of the on current.
redthrowaway 15y ago
I'm regularly impressed with the mods over at /r/asks Jen e and how high they've been able to keep the SNR.
- redthrowaway 15y ago
  That would be /r/askscience. Thanks iPhone, helpful as always.
foolinator 15y ago
CPU speed isn't a bottleneck anymore. These days improving caching, threading, and increasing the bus/memory speed have been the primary contributors to speeding up a computer. Once those bottlenecks close a bit you'll see those numbers begin to rise again.
ChuckMcM 15y ago
The answer is 'simple' it comes in four parts; 1) Transistors dissipate the most power when they are switching (this is because they transit their linear region). So the more they switch the more power they dissipate, thus the power dissipation of any transistor circuit is proportional to its switching frequency. 2) Silicon stops working reliably above 150 degrees C, this is due to thermal effects in the silicon overwhelming its electrical characteristics. One way to think about it is that at 150 degrees C the silicon lattice structure is vibrating so hard because of heat the electrons can't move anymore. 3) Lithography and manufacturing techniques have increased the number of transistors per square millimeter of silicon exponentially over the years so the number of transistors has been observed to double every 18 months or so. 4) The ability to channel heat from silicon to the outside air is limited by the thermal conductivity of silicon and the ceramics used to encase it. So those four parameters create a 'box' which is sometimes called the 'design space.' If you build a chip that is inside the box it works, if one of the parameters goes outside the box it fails. In the great Mhz race of 1998 clock rates were pushed up which caused heat dissipation to go up, and transistor counts were going up too, so you got an n^2 effect in terms of heat dissipation. The race was powered by consumers who used the single number to compare machines (spec wars). It was unsustainable. The end of that war occurred when AMD introduced multi-core (two cpus for the price of one!) architectures. And Intel had the largest design failure in its history when it scrapped the entire Pentium 4 microarchitecture after realizing it would never get to, much less past 4Ghz as they had promised. AMD proved that for user visible throughput, multiple cores could give you a better net gain than a faster CPU. This side stepped the n-squared problem by having twice the number of transistors but running at the same clock rate, so the heat only went up linearly rather than exponentially. It was a pretty humbling moment for Intel. That begat the 'core wars' where Intel and AMD have worked to give us more and more 'cores'. The heat problem was still there, but it was managed with transistor design since the frequencies were staying flat. Recently, some new transistor designs and system micro-architectures, have combined with the inevitable flattening of performance gains from multiple cores (see Amdahl's law), to give us 'turbo-boost' type solutions, where only one core runs at higher speed (side stepping Amdahl) at the expense of down clocking or even turning off other cores (sidestepping the frequency component of power increases). Another technology on the horizon (which used to be only for the military guys) is SoD or Silicon-on-Diamond. Diamond is a wonderful conductor of heat and so if you make your processor on a diamond subtrate you can pull lots of heat out into an attached cooling system. Get ready for 7" x 7" heat management assemblies though that attach to these things. Or alternatively a new ATX type form factor that includes something that looks like a power supply but is a chiller that attaches via tubes to the processor socket.
jeremysalwen 15y ago
>What would happen if you added a second compressor loop with its cold side on the hot side of the first one? What if you added a third one? You've now got 3 stage cascade phase change(compressors cool stuff by compressing gas into a liquid, then letting it suck up thermal energy while decompressing/evaporating back into a gas elsewhere, i.e. phase change) cooling on one end, and a spectacularly inefficient heater on the other. Now wait a second... that's not just wrong, that's precisely the opposite of reality. If you have a heat pump, it must be more efficient than a simple heating element. If it at all cools the processor, by the simple laws of thermodynamics, it must heat the room more than any process which simply converts the work directly to room heat.
Symmetry 15y ago
The main problem is that leakage current has started to become a problem[1]. Back in the day designers could just scale down features and rely on the reduced capacitance of the smaller areas to lower power usage enough to let them put in more logic. Unfortunately that only reduces active power, not leakage power. Transistors have started leaking more now that they're smaller. You can reduce leakage by lowering the voltage your processor operates at, but that also causes a reduction in the frequency that your transistors flip at because your logic voltage becomes smaller with respect to the transistor threshold voltage, meaning less current but unit of charge you have to move. Modern devices are also tending to run up against saturation velocity[2] now, limiting their switching speed still further. You certainly could increase clock speed by increasing the voltage you put into a chip, and just accepting that you're going to have more leakage current and more wasted power. But we're already close to the edge of what chips can dissipate right now. You can try having less logic between clock latches, meaning you have a higher clock speed for your switching delay. However, this increases the ratio of latches to everything else so its a matter of diminishing returns. It also means that you've pushed your useful logic further apart, and now you have more line capacitance too. Finally, you can decrease the temperature of your silicon to substantially reduce the amount of leakage you get. This will let you raise the voltage safely, letting you attain faster switching speeds. The only problem is that this requires expensive cooling devices. [1]http://en.wikipedia.org/wiki/Leakage_%28semiconductors%29 http://en.wikipedia.org/wiki/Leakage_%28semiconductors%29 [2]http://en.wikipedia.org/wiki/Saturation_velocity http://en.wikipedia.org/wiki/Saturation_velocity

257 points by NARKOZ 15y ago

Because scaling limits. The stuff we're already getting uses very highly doped silicon. You could go smaller or faster if you could dope it more to keep the field characteristics viable, but more doping would screw up the silicon lattice. "More" also generally means an orders-of-magnitude increase. There are a few alternative processes and materials, but they're costly as all hell and hard to do in bulk.

jacquesm 15y ago

I'm probably in a very small minority but I think that the 'free ride' we got from Moore's law in terms of transistor density leading to an increase in clock frequency has caused us to be locked in to a situation that is very much comparable to the automobile industry and the internal combustion engine. If it weren't for that we'd have had to face the dragons of parallelization much earlier and we would have a programming tradition solidly founded on something other than single threaded execution. Our languages would have likely had parallel primitives and would be able to deal with software development and debugging in a multi-threaded environment in a more graceful way. Having the clock frequency of CPUs double on a fairly regular beat has allowed us to ignore these problems for a very long time and now that we do have to face them we'll have to unlearn a lot of what we take to be un-alterable. I'm not sure about much about the future, the one thing I do know is that it is parallel and if you're stuck on waiting for the clock frequency increases of tomorrow you'll be waiting for a very long time, and possibly forever.

tezza 15y ago
I think we would just have run into Amdahl's Law earlier. http://en.wikipedia.org/wiki/Amdahl%27s_law http://en.wikipedia.org/wiki/Amdahl%27s_law . Basically you don't get a free pass for parallelising things. . If 90% of a task is parallelizable then the maximum speedup you can get with infinite cores is 10x
- larsberg 15y ago
  Indeed, we see this today with our compiler (Manticore). On our 48-core AMD and 30-core Intel boxes, we now routinely have flattening speedup curves due to the small sequential portions of even our supposedly "embarrasingly parallel" benchmarks. Compilers, even icc, are still shockingly bad at making good use of the x86_64 instruction set for sequential code. Part of that, of course, is due to C. But part of it is also our (my) fault as compiler writers because even with fantastic type information and unambiguous language semantics we emit shockingly dumb code.
  - jules 15y ago
    Can you elaborate on x86_64 code generation? (are you referring specifically to the vector instructions?) What do you think are the most promising directions to improve in this area?
    - larsberg 15y ago
      Yes, certainly the vector instructions. There are a few keys issues many C compilers seem to run into today: - Loop unroll identification is really bad. For example, ICC will unroll and turn a single-level loop with a very obvious body into streaming stores if the increment is "i++" but not if it is the constant "i+=1". - The register allocation problem has some subtelties. Many of the SSE registers overlap the name of the multiple packed-value register with those of the individual ones (e.g. "AX = lower 16 of EAX"), so knowing that you want four numbers to be in the right place without additional moves means a little bit more thinking. But, there's also very little control-flow analysis done or global program analysis done except for some basic link-time code generation and profile-guided optimization. There's a lot you can do (e.g. cross-module inlining; monomorphizing to remove uniform representation; dramatic representation changes of datatypes), though admittedly some of it requires a more static language with some additional semantic guarantees.
- jacquesm 15y ago
  You're right, there is no free pass. Let me give you one example of how the wrong habits have become embedded in how we think about programming because of the serial nature of former (and most current) architectures: One of the most elementary constructs that we use is the loop. Add four numbers: set some variable to 0, add in the first, the second, the third and finally the fourth. Return the value to the caller. The example is short because otherwise it would be large, repetitive text. But you can imagine easily what it would look like if you had to add 100 numbers in this way, and 'adding numbers' is just a very dumb stand-in for a more complicated reduce operation. That 'section' could be called critical and you'd be stuck at not being able to optimize that any further. But on a parallel architecture that worked seamlessly with some programming language what could be happening under the hood is (first+second) added to (third+fourth). You can expand that to any length list and the time taken would be less than what you'd expect based on the trivial sequential example. Right now you'd have to code that up manually, and you'd have to start two 'threads' or some other high level parallel construct in order to get the work done. As far as I know there is no hardware, compiler, operating system or other architectural component that you could use to parallelize at this level. The bottle-neck is the overhead of setting things up , which should be negligible with respect to the work done. So parallelism would have to be built in to the fabric of the underlying hardware with extremely low overhead from the language/programmers point of view in order to be able to use it in situations like the one sketched above. Those non-parallelizable(sp?) segments might end up a lot shorter once you're able to invoke parallel constructs at that lower level.
nknight 15y ago
Not sure why you think you're expressing a minority opinion, you're stating generally accepted fact. We hit the soft limit years ago, that's why Intel finally dumped the Pentium 4, they realized they couldn't make it scale. Everything since has been about finding ways to do more with fewer cycles, and more research and education on parallelization at all levels (from on-die branch prediction up to google-scale distributed systems). I don't know of anyone who disputes this in principle.
- repsilat 15y ago
  It's generally accepted fact that "the free ride is over". It's more difficult to argue that we'd be better off if it had happened sooner, that we'd escape more quickly to better global optima if the local optimum we're stuck in wasn't quite so deep. Improvements to the processors we've made by adding more cache, executing instructions out of order, predicting branches better etc are making it more difficult to escape from the conclusion we've reached. To use GP's analogy, there's now a gas station for every suburb and a garage for every house. We know better solutions are possible, but getting from here to there is going to be difficult and expensive, and it could be worse than the status quo for the early adopters in the short term.
- adambyrtek 15y ago
  You are right, this has been predicted some time ago. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software[1] from 2005 is the seminal essay on this subject. [1] http://www.gotw.ca/publications/concurrency-ddj.htm http://www.gotw.ca/publications/concurrency-ddj.htm
doyoulikeworms 15y ago
I don't mean this as a backhanded compliment, but you're in no way in the small minority. You've very eloquently explained what pretty much everyone considers to be the actual situation.
JoshTriplett 15y ago
Moore's Law still applies today; the number of transistors continues to double every couple of years. However, the transistors no longer go towards making clock speeds faster; instead, we get more parallel cores, and more impressive instruction sets. And I agree that we've taken too little time to look at parallelism. In particular, our current approaches to concurrency (such as mutual exclusion or transactions) don't actually provide much in the way of useful parallelism; they just serialize bits of the code that access shared data. We don't actually have many good algorithms that allow concurrent access to the same data, just concurrent access to different data. Currently writing my dissertation on exactly this topic: a generalized construction of scalable concurrent data structures, which allows concurrent access to the same data from multiple threads without requiring expensive synchronization instructions.
- JulianMorrison 15y ago
  Clojure's data structures are rather good for "concurrent access to the same data". References change value, but values don't change. The references are protected by read/write locks but the values in them need no protection once they have been extracted and while they are being used.
dhughes 15y ago
Even way back in the mid 90s debated getting a Pentium Pro (two CPU) because I couldn't see how a CPU could keep getting faster. But I think I needed Win NT which was too expensive and I was still new to Linux.

xxcode 15y ago

High(er) Frequency means that you have to run at a higher core voltage (this is, in part, because gate propagation delay is inversely proportional to bias voltage, i.e., the voltage corresponding to a 'high' or 1 bit). You have to decrease the propagation delay so that the clock tick gets everywhere in the processor quickly (one part of the clock doesn't lag the other parts, called clock skew). So in order for things to run faster, you'd have to run it at a higher V(bias). Now that means that there are higher thermal costs (things get hotter) - heat produced is proportion to voltage. So its now mostly a thermal management problem. This is the primary problem in the newer chips. Even though we can pack in more transistors, we can't get signals among them faster without higher V and making it run too hot. Therefore, our solution is to use the extra transistors to create a separate new processor, running with a different clock, so the 'tick' doesn't have to reach all parts of this rather big chip, but just needs to be synchronized intra-core.

archangel_one 15y ago
Right, but decreasing the size of the chip means that you effectively can get signals around it faster (because they don't have as far to go) and allows them to be run at lower voltages as well - modern CPUs seem to be generally around 1V, but 10 or 20 years ago they were around 2V, so there is (or has been at least?) a reduction in that over time as well.
shabble 15y ago
I'm curious if asynchronous logic will get brought back in as time goes on. Multi-core is essentially desynchronising the individual cores since (iirc) clock generation and distribution is one of the most expensive parts of the processor, in both energy and size. Historically, it lost out because of the added complexity of handshaking/synchroniser logic scattered all over the place, and the mess a mishandled metastable condition propagating through the system could cause. How that we've got transistors to burn, however, and routing is no longer done on large empty floors with crepe tape...
- copper 15y ago
  Well, Handshake did make an asynchronous ARM core not too long ago, and Achronix has a nice business in async FPGAs, so the idea isn't dead. That said, I'm not sure (though I'd love to be proved wrong) that the idea will really go big again. Synchronous chips are still easier to reason about. By far the most expensive real estate on a typical processor is on-chip RAM, and that really does need a clock. Sure, clock-tree synthesis is complex enough that you may even still be able to start up a company selling a tool for it, but it's still possible for a few reasonably competent engineers to do within some weeks.

neuroelectronic 15y ago

Because we've been designing around electromagnetic interference instead of designing with it. A lot of energy is wasted as heat and this heat has to be managed. Even the name electromagnetic "interference" tells you this. It's a conceptual waste that creates an energy waste. Abstraction will only get you so far when your abstraction is fundamentally flawed.

DiabloD3 15y ago

I wish people would quit asking this question. This is just another case of the Mhz myth. Who cares what the clock speed is if modern CPUs can execute instructions 2-4x faster per clock than they did 30 years ago. Go look at the Bulldozer design, 2 hardware decoder/scheduler engines, 4 integer ALUs, 2 fp ALUs, all per core... A shared L3 cache per socket that is owned by the memory controller and is socket-local to other sockets (ie, all memory controllers conspire to cache system memory efficiently and synchronously know what is cached across all sockets)... And the memory controllers also accept memory requests from ANY core on the Hypertransport bus, no matter which socket, and multi-socket boards commonly have one memory bank per socket, thus 4 sockets of dual channel DDR3-1600 would indeed give 820 gbit/sec of bandwidth that can be accessed (almost) in full by any individual core[1]... The ALUs have execution queues, and any thread (currently 2 per core) can schedule instructions on it to maximize ALU packing... And you can now buy Bulldozers for Socket G34 that have 16 threads/8 cores per socket, and G34 boards usually have 4 sockets. So again, who cares what the mhz is? [1]: A 4 socket setup has 4 or 6 Hypertransport links, on AM3+ and G34+ sockets this would be HTX 3.1 16bit wide links running at 3.2ghz, or 204 gbit/sec per link. On a 4 socket ring, that would be 204 gbit/sec off each neighbor's memory bank, plus another 204 gbit/sec (also the speed of dual channel DDR3-1600) from the local memory bank, thus leading to 612 gbit/sec that could be theoretically saturated by a single core. On a 4 socket full crossbar, it would be the full 820 gbit/sec.

dchest 15y ago
Who cares what the clock speed is if modern CPUs can execute instructions 2-4x faster per clock than they did 30 years ago. If you could increase clock speed on these modern processors twofold, would their performance improve?
- jlouis 15y ago
  Not necessarily. The fact is that you could probably do just exactly that by making the pipeline deeper. But making the pipeline deeper has a price: your control logic becomes much more complex and emptying the pipeline is more expensive. The question is then: does the price you pay become larger than the gain. As this is not happening I have a good guess :) Historically, the Pentium 4 is an example of a Mhz-oriented design. The pipeline was made ridiculously deep. This meant that when you had heavy floating point intensive work, then the Pentium 4 was very very fast. Essentially this was because you could fill up the pipeline in the CPU and you have relatively few jumps in that code. It was just a processing job. On the other hand, the P4 suffered for almost any other task. Even to the point where a more beefy Pentium 3 (Tualatin) could beat it. Intel chose a path which was based on the P3 design for their Pentium-M CPU and that is the design which guided Core, Core 2 Duo, Core i7 and so on. So it is possible, but it is not a given it would lead to faster CPUs. Mhz is but one of the knobs you can turn. The problem we are facing is that all the parallelism we can squeeze out of a sequential program has been done. Modern CPUs dynamically parallelizes what can be run concurrently. But to gain more, now, you need to write programs in a style where they expose more parallelism. Welcome to parallel programming :)

iradik 15y ago

Donald Knuth on multicore (2008): Andrew: Vendors of multicore processors have expressed frustration at the difficulty of moving developers to this model. As a former professor, what thoughts do you have on this transition and how to make it happen? Is it a question of proper tools, such as better native support for concurrency in languages, or of execution frameworks? Or are there other solutions? Donald: I don’t want to duck your question entirely. I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the "Itanium" approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write. Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX.[1] How many programmers do you know who are enthusiastic about these promised machines of the future? I hear almost nothing but grief from software people, although the hardware folks in our department assure me that I’m wrong. I know that important applications for parallelism exist—rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years. Even if I knew enough about such methods to write about them in TAOCP, my time would be largely wasted, because soon there would be little reason for anybody to read those parts. (Similarly, when I prepare the third edition of Volume 3 I plan to rip out much of the material about how to sort on magnetic tapes. That stuff was once one of the hottest topics in the whole software field, but now it largely wastes paper when the book is printed.) The machine I use today has dual processors. I get to use them both only when I’m running two independent jobs at the same time; that’s nice, but it happens only a few minutes every week. If I had four processors, or eight, or more, I still wouldn’t be any better off, considering the kind of work I do—even though I’m using my computer almost every day during most of the day. So why should I be so happy about the future that hardware vendors promise? They think a magic bullet will come along to make multicores speed up my kind of work; I think it’s a pipe dream. (No—that’s the wrong metaphor! "Pipelines" actually work for me, but threads don’t. Maybe the word I want is "bubble.") From the opposite point of view, I do grant that web browsing probably will get better with multicores. I’ve been talking about my technical work, however, not recreation. I also admit that I haven’t got many bright ideas about what I wish hardware designers would provide instead of multicores, now that they’ve begun to hit a wall with respect to sequential computation. (But my MMIX design contains several ideas that would substantially improve the current performance of the kinds of programs that concern me most—at the cost of incompatibility with legacy x86 programs.) Source: http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856

JoshTriplett 15y ago

We've gotten very close to physical limits. Quick back-of-the-envelope estimate: if electrons traveled at the speed of light through silicon (they don't), then in 3GHz, an electron could travel .1 meters. In reality, electrons in silicon travel quite a bit slower than that. Net result: electrons can barely cross the diameter of the chip in one cycle, even without gate propagation delays and other factors limiting work done per cycle. So, if you want data from a tiny distance away, such as a local register, you can grab it and do something simple with it in one cycle. If you need data from any further away, forget about it; cache takes longer, another core takes even longer, and memory takes far longer.

Confusion 15y ago
Fun fact: electrons in an metallic wire under a potential difference move only in the order of mm/s. See e.g.[1] As electrical signals still travel at about half the speed of light, that seems besides the point. However, electrical signals do not need to span the entire width of a chip in order to have an effect. That is true for your example of accessing memory, but not for the actual calculations happening inside the CPU. On each clock cycle, all transistors are 'fed' by the transistors before it. The state of a transistor only depends on the states of the immediately connecting transistors on the clock cycle before it. That means the signal only has to travel the length of a single transistor on each clock cycle. We could have CPU's working at 3THz and a much larger focus on the difference between CPU-bound and IO-bound tasks. [1] http://amasci.com/miscon/speed.html http://amasci.com/miscon/speed.html
- jacquesm 15y ago
  The easiest to understand analogy to illustrate this that I've found to date is to imagine a tube full of marbles, push one more marble in on one end and another one will pop out instantly on the other end. As long as the marbles are all the same colour it is as though the marble you pushed in has miraculously teleported to the far end of the tube. It appeared to have moved at the speed of light even though in reality all the marbles have shifted only an amount equal to the diameter of a single marble.

karolist 15y ago

No idea. I have my E8400 still kicking ass at 4.2Ghz on air.

karolist 15y ago
Ok, let me explain to the downvoters. As the top comment on reddit currently states, there's no issue with speed of light, the issue is with heating. And there's no "3.5Ghz" limit, stock, mass produced heating solutions limit us. People get all sorts of crazy clock speeds by improving their cooling, mine's on Zalman 9500 fan and has no stability issues to run at 4.2Ghz (stock 3.0Ghz).

its_so_on 15y ago

this is why: http://www.google.com/search?q=c+%2F+3.5+Ghz http://www.google.com/search?q=c+%2F+3.5+Ghz that's a theoretical maximum. you increase Ghz, you have a shorter theoretical maximum length of path electricity can take through your chip. An i7 is not that small. You would have to shrink things further and further to get a smaller chip with shorter paths in it, which is what new fabrication methods have been about. Obviously this is very difficult. Sure, chips could be even faster if they were just a few atoms across, but who would expect you to do meaningful computation in that size, or to be able to manufacture that.

perokreco 15y ago
This is completely false. You can read why in the comments above.

kashifr 15y ago

According to the Sandia's Cooler whiter-paper pdf: http://prod.sandia.gov/techlib/access-control.cgi/2010/100258.pdf http://prod.sandia.gov/techlib/access-control.cgi/2010/10025... the limit is due to a "Thermal Brick Wall". Basically due to a lack of progress in heat exchanger technology. I have visualized this "Brick-Wall" as a graph with data from Wikipedia pdf: http://dl.dropbox.com/u/3215373/Thermal-Brick-Wall.pdf http://dl.dropbox.com/u/3215373/Thermal-Brick-Wall.pdf

tibbon 15y ago

So what confuses me is that we've seen tech demos (and overclockers) push CPU speed to 4 to 10ghz. Are those gains so artificially made that they just can't be replicated at scale in the public market? We can get them to go faster, just seemingly not for the public. It was weird to buy my new Macbook Pro and after 3+ years, it was .2ghz slower than my old one. Now of course it has more cores, better instructions, etc... but it was still a weird thing. Apple's done a great job of explaining the benefits of new ones to the consumers - they don't. I'm not being sarcastic. At the end of the 90's (and still largely today for most PC companies) its all about specs. Apple sold what you can do with each computer instead in a good, better, best format. I bet a large amount of computers sold at the Apple store never have the sales associate mention the clock speed.

beschizza 15y ago
Perhaps because the gains are typically made with the help of cooling systems too unwieldy and unreliable for mass consumption.
j-g-faustus 15y ago
Here's an article describing what it takes to reach those speeds: http://www.tomshardware.com/reviews/5-ghz-project,731.html http://www.tomshardware.com/reviews/5-ghz-project,731.html The article is a few years old, and the clock limits have changed, but the principles of reaching them are the same. As for replicating it at large in the public market, I don't anticipate that liquid nitrogen feeds will be ubiquitous anytime soon :)
- apaprocki 15y ago
  The top IBM POWER7 CPU is clocked at 5ghz and isn't cooled with liquid nitrogen.
  - j-g-faustus 15y ago
    As I said, it's a few years ago. Today you can get 5 GHz with Sandy Bridge on air (although it might entail testing a few dozen CPUs to find one that can reach that high). But the OP was referring to speeds up to 10 GHz, those still need something special. Here's a current Guiness record, 8.4 GHz using liquid helium: http://www.youtube.com/watch?v=UKN4VMOenNM http://www.youtube.com/watch?v=UKN4VMOenNM Other materials might potentially clock higher, an IBM research prototype chip reached 500GHz: http://news.bbc.co.uk/2/hi/technology/5099584.stm http://news.bbc.co.uk/2/hi/technology/5099584.stm

microarchitect 15y ago

This is a good example of why science isn't a popularity contest. The top voted reply makes some vague noises about vt-scaling and leakage. It then claims that we "don't get a very good "off" if the threshold voltage is too low". This is incorrect. Leakage doesn't degrade the logic values for CMOS-style logic, which is the vast majority of the digital logic in the world. The real issue which the OP may or may have been trying to get at is that leakage power eats into the chip's power budget. Since we'd rather not burn our budget on leakage, we reduce leakage by increasing the threshold voltage. But unfortunately, this comes at the cost of frequency. The other very important issue is that of power-density. There's a famous graph that Shekar Borkar of Intel [1] made showing that if we continued to ignore power dissipation issues like in the past our chips would run ridiculously hot (IOW, they wouldn't work at all because they'd just burn themselves to death). There are also other issues like the fact that your wires start acting like antennas at 5+ GHz and that reliability concerns like electromigration and dielectric breakdown are getting worse with newer technologies. A much more recent and reliable (not to mention highly-cited) reference on scaling and power issues is [2]. [1] I found a copy here: http://www.nanowerk.com/spotlight/id1762_1.jpg http://www.nanowerk.com/spotlight/id1762_1.jpg [2] http://www-vlsi.stanford.edu/papers/mh_iedm_05.pdf http://www-vlsi.stanford.edu/papers/mh_iedm_05.pdf

mbell 15y ago
While I agree that power is the primary issue leakage does have a correlation with "degrading the off" value. Specifically the effects of drain induced barrier lowering becomes very significant in the sub-threshold region as the channel length is reduced. This has the effect of both increasing drain current (leakage) and making the transistor more difficult to turn off, that is a larger gate bias is required to turn the transistor off. While "leakage" isn't the cause, you do get leakage and a harder to turn off transistor at the same time, at least for this type of leakage.
- microarchitect 15y ago
  Hmm. In a CMOS structure with a weakly turned off device, you'd need the effective off resistance to be more than 1/20th of the effective on for the logic value to degrade by roughly 5%. Did we have such leaky transistors for 130nm/90nm when the shift happened? A quick calculation I did with a 90nm model for I have some parameters with vt=0.3, vdd=1.2, subthreshold slope=90mV/decade and dibl coeff=0.1 seems to suggest that leakage would still be < 1/100th of the on current.

redthrowaway 15y ago

I'm regularly impressed with the mods over at /r/asks Jen e and how high they've been able to keep the SNR.

redthrowaway 15y ago
That would be /r/askscience. Thanks iPhone, helpful as always.

foolinator 15y ago

CPU speed isn't a bottleneck anymore. These days improving caching, threading, and increasing the bus/memory speed have been the primary contributors to speeding up a computer. Once those bottlenecks close a bit you'll see those numbers begin to rise again.

ChuckMcM 15y ago

The answer is 'simple' it comes in four parts; 1) Transistors dissipate the most power when they are switching (this is because they transit their linear region). So the more they switch the more power they dissipate, thus the power dissipation of any transistor circuit is proportional to its switching frequency. 2) Silicon stops working reliably above 150 degrees C, this is due to thermal effects in the silicon overwhelming its electrical characteristics. One way to think about it is that at 150 degrees C the silicon lattice structure is vibrating so hard because of heat the electrons can't move anymore. 3) Lithography and manufacturing techniques have increased the number of transistors per square millimeter of silicon exponentially over the years so the number of transistors has been observed to double every 18 months or so. 4) The ability to channel heat from silicon to the outside air is limited by the thermal conductivity of silicon and the ceramics used to encase it. So those four parameters create a 'box' which is sometimes called the 'design space.' If you build a chip that is inside the box it works, if one of the parameters goes outside the box it fails. In the great Mhz race of 1998 clock rates were pushed up which caused heat dissipation to go up, and transistor counts were going up too, so you got an n^2 effect in terms of heat dissipation. The race was powered by consumers who used the single number to compare machines (spec wars). It was unsustainable. The end of that war occurred when AMD introduced multi-core (two cpus for the price of one!) architectures. And Intel had the largest design failure in its history when it scrapped the entire Pentium 4 microarchitecture after realizing it would never get to, much less past 4Ghz as they had promised. AMD proved that for user visible throughput, multiple cores could give you a better net gain than a faster CPU. This side stepped the n-squared problem by having twice the number of transistors but running at the same clock rate, so the heat only went up linearly rather than exponentially. It was a pretty humbling moment for Intel. That begat the 'core wars' where Intel and AMD have worked to give us more and more 'cores'. The heat problem was still there, but it was managed with transistor design since the frequencies were staying flat. Recently, some new transistor designs and system micro-architectures, have combined with the inevitable flattening of performance gains from multiple cores (see Amdahl's law), to give us 'turbo-boost' type solutions, where only one core runs at higher speed (side stepping Amdahl) at the expense of down clocking or even turning off other cores (sidestepping the frequency component of power increases). Another technology on the horizon (which used to be only for the military guys) is SoD or Silicon-on-Diamond. Diamond is a wonderful conductor of heat and so if you make your processor on a diamond subtrate you can pull lots of heat out into an attached cooling system. Get ready for 7" x 7" heat management assemblies though that attach to these things. Or alternatively a new ATX type form factor that includes something that looks like a power supply but is a chiller that attaches via tubes to the processor socket.

jeremysalwen 15y ago

>What would happen if you added a second compressor loop with its cold side on the hot side of the first one? What if you added a third one? You've now got 3 stage cascade phase change(compressors cool stuff by compressing gas into a liquid, then letting it suck up thermal energy while decompressing/evaporating back into a gas elsewhere, i.e. phase change) cooling on one end, and a spectacularly inefficient heater on the other. Now wait a second... that's not just wrong, that's precisely the opposite of reality. If you have a heat pump, it must be more efficient than a simple heating element. If it at all cools the processor, by the simple laws of thermodynamics, it must heat the room more than any process which simply converts the work directly to room heat.

Symmetry 15y ago

The main problem is that leakage current has started to become a problem[1]. Back in the day designers could just scale down features and rely on the reduced capacitance of the smaller areas to lower power usage enough to let them put in more logic. Unfortunately that only reduces active power, not leakage power. Transistors have started leaking more now that they're smaller. You can reduce leakage by lowering the voltage your processor operates at, but that also causes a reduction in the frequency that your transistors flip at because your logic voltage becomes smaller with respect to the transistor threshold voltage, meaning less current but unit of charge you have to move. Modern devices are also tending to run up against saturation velocity[2] now, limiting their switching speed still further. You certainly could increase clock speed by increasing the voltage you put into a chip, and just accepting that you're going to have more leakage current and more wasted power. But we're already close to the edge of what chips can dissipate right now. You can try having less logic between clock latches, meaning you have a higher clock speed for your switching delay. However, this increases the ratio of latches to everything else so its a matter of diminishing returns. It also means that you've pushed your useful logic further apart, and now you have more line capacitance too. Finally, you can decrease the temperature of your silicon to substantially reduce the amount of leakage you get. This will let you raise the voltage safely, letting you attain faster switching speeds. The only problem is that this requires expensive cooling devices. [1]http://en.wikipedia.org/wiki/Leakage_%28semiconductors%29 http://en.wikipedia.org/wiki/Leakage_%28semiconductors%29 [2]http://en.wikipedia.org/wiki/Saturation_velocity http://en.wikipedia.org/wiki/Saturation_velocity