Why CPU Frequency Stalled (2008)
spectrum.ieee.org
spectrum.ieee.org
Multi core wasn't some great idea. They were forced to do it. Intel hit the power wall first and then went multicore.
But around 2003, chipmakers found they could no longer reduce the operating voltage as sharply as they had in the past as they strived to make transistors smaller and faster. That in turn caused the amount of waste heat that had to be dissipated from each square millimeter of silicon to go up. Eventually designers hit what they call the power wall, the limit on the amount of power a microprocessor chip could reasonably dissipate. After all, a laptop that burned your lap would be a tough sell. --David Patterson.
A few power wall cites:
https://www2.eecs.berkeley.edu/bears/presentations/06/Patter... http://spectrum.ieee.org/computing/software/the-trouble-with... http://www.edwardbosworth.com/My5155_Slides/Chapter01/ThePow...
This article strikes me as revisionist history.
http://booksite.elsevier.com/samplechapters/9780123747501/Pa...
Thermodynamics was all figured out in the days of steam engines and we're kinda stuck now at a maximum.
If you examine the equation there's no reason you can't dump 1000 watts if you're willing to heat the silicon die to 1000 C like a glowing vacuum tube.
However (insert massive hand waving) there are characteristics of silicon doping vs temps and all this hand wavy stuff that depends on deg C such that I assure you that you can't build a junction that works with todays technology at BOTH room temp and 1000C (so you'd have to preheat your CPU, perhaps with a flame?) or worst case scenario with current chemical processes I'm not sure you can build a junction that works at 1000C at all. I'd have to think about that for awhile.
Anyway pull most datasheets and even for bulk power transistors (like a RF amp or the switching transistors in your power supply) the max die temp is 125C or 150C but I don't casually remember ever seeing a transistor with a max die temp over 175C (which is hardly scientific proof there's no exotic chip out there that runs at 200C or 400C...)
Your stereotypical small signal bipolar NPN like a 2N3904 might max out junction temp at 150C. Some of the graphs like collector leakage current are exponential with temp and by 150C you better design that leakage into your circuit. Note that at a couple hundred degrees per watt thermal resistance from junction to ambient you're not going to dump much power in a small signal transistor like that, but its certainly enough to run relays and LEDs and stuff, and the same general temp limits apply to all transistors. Some beastly multi-GHz multi-watt monster might have a staggeringly lower thermal resistance but the junction temp limit is still gonna be 150C or so.
I guess in summary if off the shelf you could run junctions at 500C then heat wouldn't be an issue or limiter for another, I donno, decade or two. But the 150 or 175 or whatever limit is a hard physics limit with current tech, so ...
If you want to impress an EE with space-ship x-files area 51 BS give him a semiconductor that works while glowing orange hot or so. That would have pretty interesting performance specs, I bet. Its also impossible AFAIK at current human technology levels. Either that or a semiconductor with room temperature superconductive bond wires. Which is more likely first? Who knows.
Here are some MOSFETs that are rated to operation at 300C(!)
http://www.x-relsemi.com/EN/Documentation/Datasheet/DS-00113...
Not cheap.
So no - you cannot make silicon run at 500C or 1000C with any reliability. You would have to build gate-level thermal control into the circuit, which would immediately adds a huge penalty in speed/size/cost.
Besides, no one really wants a die with a kW TDP.
It was bad enough with older MBs/procs that pumped out enough heat to keep a room toasty.
If you push that, you start needing climate control for domestic/office computing, which is going to be far too expensive for everything except high end enterprise applications.
Cooling is already a huge engineering problem for server farms. Making it harder by an order of magnitude won't win many friends.
And then you have the fact that most jobs can be parallelised. There are relatively few applications that can't be made faster by throwing more processors at the problem, supporting them with faster interconnects, and improving the throughput of the software.
It's not that there are no applications waiting for much faster processors. It's more that everyone is waiting for a post-silicon (optical?) breakthrough to make them affordable.
Another issue with running nanometer-scale chips hot, from what I understand, is that the dopants will start to diffuse into the silicon, and because the feature size is so small, you eventually get transistor failures.
How about a chip with cores that are specc'ed for low-temp, and cores that are specc'ed for high-temp, where the high-temp cores are designed to be the heat-sink for the low-temp cores? The low-temp cores would be something like a "starter motor."
So a CPU with a burned out hot core is still usable as a low performance cold only machine but a CPU with a burned out cold core can only be booted if you hold a match to the heatsink for awhile... that will be an interesting troubleshooting technique for youtube videos.
It's just impractical, especially getting everything cooled equally in the presence of hot/cold spots.
Temperature is ultimately limited by sped up diffusion of doping and such, temperature limits in surrounding materials (eg epoxy-based chip carriers or epoxy-based case material), and reduced performance due to increasing leakage currents.
Ten years ago, the single-core Pentium 4 stalled just shy of 4GHz. Today's high-end Core i7's also have a stock frequency around 4GHz, though of course they're at least ten times more powerful. AMD tried 5GHz at one point, but that was just a gimmick and most of their current models stick to 4GHz or less.
Despite having radically different designs and process sizes, roughly the same frequency remains the point after which energy consumption just runs out of control. Performance-wise it doesn't matter because we've gone multi-core and found ways to get more work done per clock cycle, but I wonder why the top frequency seems to be so consistent.
However, It's also clear what gravypod is trying to say. The architecture itself has a greater influence on the "processing power" nowadays because the clock has reached physical limits and can't be increased much further without getting expensive (see IBM Power Sytems). Bottomline is that you can't compare CPUs by frequency alone, but it was never any different, the architectures 15 years ago just sucked so hard that all of them were too similar regarding instructions per cycle.
I think we can blame AMD for that line of thinking, they had to push hard against Intel during a time where everyone used clock frequency to compare CPUs.
*edit: Sorry I remembered it wrong, the commonly used power equation is P = C x V^2 x f (capacity, voltage, frequency). Power is linear dependent on the frequency!
I don't see how this is ultimately true.
The amount of electrons needed to flip a capacitor is constant given that the voltage is constant. The more often you flip, the more current you need per time.
The amount of electrons needed to flip a capacitor is proportional to the voltage. So, lower voltage means a) less power per electron and b) less electrons. Therefore the power is quadratic with the operating voltage.
Third, if you want to increase the frequency, at some point, you have to increase the voltage or you get errors. Then you increase frequency and voltage at the same time and your power consumption shoots up.
In the meantime I can only offer this [1] stackexchange post. Power of a CPU is definitely quadratic in f, or even worse.
[1] http://physics.stackexchange.com/questions/34766/how-does-po...
edit: I probably remembered it wrong and I now think that that the equation was P=C x V^2 x f. However, transition power effectively has an exponent much greater than 2, but that's apparently caused by the increased die temperature (according to the post on Anandtech).
e.g. ARM Cortex A7: 2,850 MIPS at 1.5 GHz
Qualcomm Krait (Cortex A15-like, 2-core): 9,900 MIPS at 1.5 GHz
Both processors have the same clock frequency, but one has over three times the processing speed in MIPS.
[1] https://en.wikipedia.org/wiki/Instructions_per_second#Timeli...
Referring to the list on wikipedia again, compare two different 4-core CPUs:
Intel Core i5-2500K 4-core: 83,000 MIPS at 3.3 GHz
Intel Core i7 875K: 92,100 MIPS at 2.93 GHz
Modern CPUs use pipelining which executes many instructions parallel. This only works well if everything goes as predicted. If you have an algorithm which works contrary to what the branch prediction thinks and a cache which does not hold the data you need, your performance goes down the drain. Those MIPS mean nothing if not put into the right context.
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-93-6.pdf
It explores the limits of instruction-level parallelism. If you had a processor that could dispatch an unlimited number of independent instructions simultaneously, how much of an improvement in common algorithms would you get?
Cache misses make CPU speed irrelevant, but when you look at your memory system it's another instance of the same problem with the same tradeoffs of frequency vs. work per cycle. And when the "right context" is waiting for the outside world, that's not the most important context.
I highly recommend taking a digital logic and computer architecture class in a CS program to understand how pipelines/instruction units are laid out (microcoding, branch prediction, pipeline stalls, macro ISA, etc.), what makes them fast/slow and challenges to implementation.
As a side note, the Tomasulo algorithm is a huge pain in the ass to do in hardware. Props to the processor engineers who are implementing modern OOO execution hardware in whatever awful proprietary HDL/IDE combo your company makes you use.
A really excellent example here are ARX (add rotate xor) algorithms in cryptography. Take BLAKE2 for example; the reference C code, compiled to plain x86-64 assembly mainly consists of long rows of addq/xorq/rorq instructions. A modern CPU manages to schedule these so efficiently that the performance difference to a hand-coded SSE or AVX version practically never matters.
If you take a peek at Haswell's port map (eg. http://images.anandtech.com/reviews/cpu/intel/Haswell/Archit... ) you'll see that there are four out of eight ports who can do integer arx operations. Since memory and addr ops got their own ports this means that even the straight addq/xorq/rorq code can almost fully utilize the core.
This is no accident, though, the algorithm was designed to take advantage of designs like this :)
GP argues that even though frequency has not increased recently, performance has, a point better made by the article.
You can't.
For instance, CPUs have sped up a lot compared to memory. As a result, if you just calculate as fast as you can, you run out of data to calculate on. Suddenly it becomes more relevant how fast you can access memory. So now we have all sorts of complicated cache mechanisms to help us keep the data to hand. Coding needs to be cache friendly as well.
If you look at CPU prices, you can see the amount of cache increases with the price.
Frequency is far from an accurate measure of performance. It doesn't take in IO, context switching, pipe lining, interrupts, and multicore systems. Even within the same family clock speed may not have much to do with performance. Clock speed is just a measure of how many times a second some increment in an operation may occur. Doesn't mean it will increment it's progress in an operation, doesn't mean the operation can't happen between then, it just means the CPU will find out about the state of that between those updates.
You also need to take into account the BPU and the vector math sections of the die which this sort of metric completely ignores.
I'd pay for having more single-threaded performance on my desktop where power is not an issue. But I guess the average user (word-processing, browsing) does not care. Gamers also don't care since they can use special hardware, because games are more easily parallelized (if you divide the screen into individual blocks, then you can just divide the rendering work to individual cores).
These two markets combined are the vast majority of all general-purpose computing devices sold. Chip companies are following the money.
The scaling conundrum is also a factor: you must employ parallelism to get performance out of modern CPUs. GPUs are entirely about parallelism. If your problem requires scaling (ex: 3D movie render farm) you get far more bang for your buck by scaling across slower but cooler machines than you'd get with fewer machines using expensive water-cooling (and the associated A/C or central condenser). You already had to do the work to employ local parallelism... scaling across machines isn't a huge leap. If you don't go parallel the best you could hope for in your wildest fevered dream would be 2-5x perf. Scaling across cores on one machine can easily match that; across machines gives you orders of magnitude.
So even for people who require peak performance and are willing to pay millions to get it the market is cooler slower multi-core CPUs.
That leaves relatively tiny portion of the market who require maximum single-core performance because they're problem can't be paralellized. At best you could get 1-5x speed up with an over-clocked water-cooled rig and some people do. That performance factor is slowly decreasing over time as feature sizes shrink.
They even show it in the article:
>underclocking a single core by 20 percent saves half the power
0.8^2 = 0.64, pretty close.