Why CPUs Aren't Getting Any Faster
technologyreview.com
technologyreview.com
As the process size drops, you can crank up the clock-speed while leaving the total heat dissipation constant. But the heat density is related to the voltage, resistance, and the amount of time the transistors spend partially on or off (we wish they were perfect switches, but they aren't really). So as you switch faster, unless you can lower the resistance or voltage (which requires changing your materials), you probably spend more and more time in a partially on or off state. This means your heat density rises to the point where you are just south of burning things out.
You make some engineering decision about the reliability you want in your chips, and calculate or test how high a heat density you can tolerate. But unless you change your materials so they use lower voltage, or invent new ways to move heat away faster, or use materials that are more conductive, you aren't upping the heat density or clock rate. But you can still make them smaller and use less power total for the same amount of computation.
This is why reversible computing (gives off less heat), diamond substrates (much higher thermal conductivity), microfluidic channels (moves heat away faster), and parallelism (larger chips = more computation) are being explored. And only the last one is practical THIS year.
One such material is the material that won the Noble Prize in physics: graphene. Graphene can increase the frequency of an electromagnetic signal, which can allow for even faster CPUs in the 500-1000 Ghz range
Source: http://web.mit.edu/newsoffice/2009/graphene-palacios-0319.ht...
Building faster processors is extremely expensive, so demand has to be a key concern for manufacturers. I still think there's plenty of demand for faster processors, and I'm sure we'll continue to see lots of innovation, but the issue doesn't seem to be as pressing as it was 10 years ago.
CPUs have passed a curve where there just aren't any killer applications demanding more CPU power. For me the biggest "wish I had a faster CPU" need has been video encoding, however recently the encoder I use switched to using the GPU for encoding and the speed improved dramatically, so even that need has declined.
But I wonder about hundreds or thousands of cores, if we'll see that and if people will start to worry that single threaded software uses ever smaller amounts of their shiny new hardware. Will there every be some magic layer that can run single threaded software on many cores?
I wrote about the end of faster clocks and start of multi-core recently: http://www.kmeme.com/2010/09/clock-speed-wall.html
I don't think that's a very good explanation of SoCs.
I would also say that forced is a bit strong. SoCs are a good solution when (1) you have a very specific task and (2) can justify/afford the cost for a specialized chip.
What does that mean? Essentially that the race for deep pipelines has ended, with 20-40 stages being the optimal depth. After that, miss penalties just hurt too much. Therefore, when you can't make the pipeline deeper, you can't make the frequency much faster, you are stuck with following process progress (which is already pretty good). So it's more tempting to go after multi-cores: same pipeline depth, more silicium, more efficient overall.
When I was working in finance as a quant, I was shocked by the amount of time code spent executing the exponential function - it is used heavily in discount curves and similar which are the building blocks of much of financial mathematics. An efficient silicon implementation would have yielded a great improvement in speed.
String processing instructions in SSE4.2: http://www.strchr.com/strcmp_and_strlen_using_sse_4.2
AES encryption instructions: http://en.wikipedia.org/wiki/AES_instruction_set
So, if you didn't know about those, give yourself a point, because you nailed it. (No sarcasm.) There's a definite trend there.
- Intel has been at the top for too long.
- x86 is to complex
- nVidia and AMD are being blocked from making x86 chips
- PCs pretty much require x86 to exist.
moving to graphine might allow for an increase in chip temp, but do you really want a processor running at a few hundred to a thousand degrees? are you willing to pump 200-2k watts into a chip? thank god that we didn't make this mistake with mobile
and most platforms use an abstraction level language
like c#, java, or javascript.
I am personally hoping that data centers really are evaluating ARM chips. The instruction set is smaller, they are lower power, and there are more producers of ARM cores, so prices are much lower. A good intel chip will cost $200-$500, while a chip with an ARM core is probably in the $25-$100 range. How much does a tegra2, A4, or snapdragon cost?
I imagine the future of data centers will be arrays of system on chip ARM cores paired with high doses of flash memory. Running your web app off of 1,000 ARM cores might cost you a few thousand a month.If you're going to criticize CISC architectures I would have done it before Intel moved to optimized RISC microcode in implementation. Arguably the greatest advancement in CPU technologies in the past couple years was the addition of hardware virtualization extensions to fulfill the Goldberg requirements. That said, I am biased because I wrote the Intel hardware virtualization layer for an HPC VMM.
So, for ARM the only reason to have 64bit is to address large memory, and drive controllers for flash can address the rest. heck if someone really wanted to do an integrated server environment they could put ram behind the drive controller.
So having a 32bit core and a 64bit gpu on chip means you can do complex scientific math, but how many web apps really need 64bit floats, ints? In a web world if you needed 64bit, just make a service on a platform that works and either proxy the request or redirect to it.
i guess mongodb would suck on a 32bit arm, but that's just because they have a lazy memory manager model. i am sure if arm got big or if someone paid 10gen to fix it, they would.
I bet most of the web could work on a large array of high frequency ARM chips.
I know that both google is working on it, and I have seen articles on facebook doing it.
It's definitely experimental right now, but I think in the next 18 months you will see more public experiments.
Mobile chips also have better power management than x86, and can go in to deep sleep and maintain cache really well.
Watch this, i know it's going to POP.
there is also evidence that nVidia is figuring out it's legal strategy for this. which has an ARM license, and bought transmeta.
Of course, I never heard about this again. Ring a bell with anyone?
My previous startup (http://eve-usa.com) sells million-dollar boxes that are essentially debuggers, just like gdb is for software, but for chips. Very cool.
I wonder if this heat could actually get high enough to recoup some energy.
As you start to shrink transistors and the spacing between them, the chips get hotter, burn more power, and throw more errors. You also get electron "leakage" where the electrons inadvertently jump between gates, so the processors become less efficient and you have to run extra fault-tolerance to check for the errors.
Multi-core and bringing all the other components up to speed is the way to go for now until a newer technology comes, like quantum computing or light based processing.
http://www.nordichardware.com/index.php?option=com_content...
IBM released a 5GHz POWER processor 2.5 years ago: http://www.theregister.co.uk/2008/04/08/ibm_595_water/
I'm not sure whether you're being serious or if you're actually claiming some sort of advanced insight here.
There has been speculation on the peak speed of processors for many, many years. I don't think they were consulting your high school reports.