MIT Graphene Multiplier May Push CPUs to 1,000 GHz(insidetech.com)
insidetech.com
MIT Graphene Multiplier May Push CPUs to 1,000 GHz
http://www.insidetech.com/news/articles/4375-mit-graphene-multiplier-may-push-cpus-to-1000-ghz
6 comments
Reading the article, it sounded an awful lot like this means we can have timing signals that run at 1000GHz. This doesn't mean anything at all about our ability to have other components actually running at that speed.
Just throwing it out there, light (potential, or any signal) can travel about 0.3mm in one picosecond, which is a clock cycle if you're operating at 1THz.
I don't know how tiny these cores will be, but based on my back-of-the-envelope calculations, it doesn't sound like it'll be too realistic if we're talking about CPU cores operating that quick.
I don't know how tiny these cores will be, but based on my back-of-the-envelope calculations, it doesn't sound like it'll be too realistic if we're talking about CPU cores operating that quick.
Well, assuming a current cpu core is ~30mm square, you would need to shrink the feature size by two orders of magnitude... so current 45nm features would need to shrink to ~500 picometers.
According to wikipedia, a 'standard atom' is between 60 and 600 picometers in diameter, so yeah, you'd need transistors the size of atoms.
Of course, this is assuming the same general processor design. You could go 3D and get everything closer together without shrinking transistors as much... or you could change the design all together.
According to wikipedia, a 'standard atom' is between 60 and 600 picometers in diameter, so yeah, you'd need transistors the size of atoms.
Of course, this is assuming the same general processor design. You could go 3D and get everything closer together without shrinking transistors as much... or you could change the design all together.
That's one option the other is using a longer pipeline.
However, the cache does not need to operate at that speed only the core so it's best to ignore the cache, but I can't find good numbers on a naked CPU. Anyway, using a 55nm GPU 285 GTX that has a 470 mm die size and 240 processor elements we can see each element is only using ~2mm of die. Which is only off by a factor of 4 so ~14nm would work.
In theory you could end up with a ~1THz GPU with ~1000 SPs and around 4000x more processing power. But it would need insane memory bandwidth etc.
However, the cache does not need to operate at that speed only the core so it's best to ignore the cache, but I can't find good numbers on a naked CPU. Anyway, using a 55nm GPU 285 GTX that has a 470 mm die size and 240 processor elements we can see each element is only using ~2mm of die. Which is only off by a factor of 4 so ~14nm would work.
In theory you could end up with a ~1THz GPU with ~1000 SPs and around 4000x more processing power. But it would need insane memory bandwidth etc.
Longer pipelines proved to be pretty much a dead end with the Pentium 4.
They're great and all when it comes to benchmarks and stuff, but their design has a number of serious drawbacks:
1) The control lines for a long pipeline are incredibly convoluted/complicated as necessitated by the movement of individual instructions from one stage to the other along the pipeline across many, many cycles (all of which involve storing the results of the current cycle to a register somewhere along the pipeline, adding immense overhead in today's systems).
2) Flushing longer pipelines is an incredibly taxing procedure. You either flush the entire pipeline and lose a huge chunk of work, basically throwing out several thousand cycles of work as a result of a single branch or value mis-prediction; or you can selectively clear the pipeline which is an extraordinarily difficult feat that involves keeping track of which operation in what order wrote back what data to which register... for dozens of operations.
They're great and all when it comes to benchmarks and stuff, but their design has a number of serious drawbacks:
1) The control lines for a long pipeline are incredibly convoluted/complicated as necessitated by the movement of individual instructions from one stage to the other along the pipeline across many, many cycles (all of which involve storing the results of the current cycle to a register somewhere along the pipeline, adding immense overhead in today's systems).
2) Flushing longer pipelines is an incredibly taxing procedure. You either flush the entire pipeline and lose a huge chunk of work, basically throwing out several thousand cycles of work as a result of a single branch or value mis-prediction; or you can selectively clear the pipeline which is an extraordinarily difficult feat that involves keeping track of which operation in what order wrote back what data to which register... for dozens of operations.
All modern PC CPU's have a pipeline.
Granted long pipelines suck, but my point was you can have a higher clock speed than the time it takes light to travel from one end of you're CPU to the other and back. One of the more interesting options IMO is to have 2 separate threads with separate registers using the same hardware so you can interleave calculations without a long pipeline. The issue becomes do you have 2 half speed virtual cores or a single high clock speed core and what do you do about instructions that take more than one clock cycle.
Granted long pipelines suck, but my point was you can have a higher clock speed than the time it takes light to travel from one end of you're CPU to the other and back. One of the more interesting options IMO is to have 2 separate threads with separate registers using the same hardware so you can interleave calculations without a long pipeline. The issue becomes do you have 2 half speed virtual cores or a single high clock speed core and what do you do about instructions that take more than one clock cycle.
Oh, I'm not denying the merits of pipelining - no one can. I'm just saying that nothing is good when taken to the extreme.
The "more interesting option" you're referring to is implemented in P4 and Nehalem under the trademark of "HyperThreading."
The "more interesting option" you're referring to is implemented in P4 and Nehalem under the trademark of "HyperThreading."
The non-marketing name is Simultaneous Multithreading (SMT), but I've never been impressed with SMT performance. I think the emerging processors that use many simpler cores will have more impact.
What about heat? Area that small operating that fast would generate an intense amount of heat.
In another only-slightly-related article (about Graphene Memory developed at Rice), they note that graphene based trasistors require 1/1,000,000th the switching power (because they leak less), and operate successfully from -75C to 200C, so it might not be an issue.
But really this is totally speculation until someone builds one.
Link to article about Graphene Memory: http://www.dailytech.com/Researchers+Create+New+Memory+from+...
But really this is totally speculation until someone builds one.
Link to article about Graphene Memory: http://www.dailytech.com/Researchers+Create+New+Memory+from+...
You're assuming that chip sizes are bounded by clock frequency. They're not. We already have "clock islands".
Perhaps we may soon start seeing clockless processors entering the mainstream?
It is just a clock multiplier. Generating high clock frequencies was never the biggest bottleneck to faster CPU speeds.
They are spinning their research to be more mainstream. This probably has better application to THz communication and imaging applications like those airport scanners that can see through clothing. Currently, they generate the THz signals using lasers.
They are spinning their research to be more mainstream. This probably has better application to THz communication and imaging applications like those airport scanners that can see through clothing. Currently, they generate the THz signals using lasers.
Modern processors already run 250 times faster than the memory system is able to feed data into it. Caches can't help to cover this lag much. I wonder how that machine might run things faster than what current processors are doing unless this memory speed problem is fixed.
By the way, human brain works at 10 Hz only (not even KHz) and can still process information faster than all these CPUs.
By the way, human brain works at 10 Hz only (not even KHz) and can still process information faster than all these CPUs.
Modern processors already run 250 times faster than the memory system is able to feed data into it.
Not true at all. The latency from memory is around 250 clocks, but that does not mean they "run 250 times faster than memory can feed data into it." Modern memory throughputs are on the order of gigabytes or dozens of gigabytes per second, rather than your claimed (2Ghz / 250) = 8 megabytes per second.
Not true at all. The latency from memory is around 250 clocks, but that does not mean they "run 250 times faster than memory can feed data into it." Modern memory throughputs are on the order of gigabytes or dozens of gigabytes per second, rather than your claimed (2Ghz / 250) = 8 megabytes per second.
the information I have about the human brain is that neurons works at about 200hz (there is variability).
It's not faster than CPUs in many things, but where it is, it wins because it is massively parallel (so that helps for pattern recognition, but not to solve difficult linear equations).
It's not faster than CPUs in many things, but where it is, it wins because it is massively parallel (so that helps for pattern recognition, but not to solve difficult linear equations).
I'm sitting in on Marvin Minsky's Society of Mind class, and he keeps reminding us that MASSIVE PARALLELISM IS NOT THE INTERESTING ASPECT OF THE MIND.
Think about playing chess. Each move, there's 30 branches to follow. If you have a million machines, you can evaluate about 2 moves ahead before parallelism runs out. If you have bad branch prediction, you'll follow all the wrong paths.
Humans beat machines at creative endeavors because computers don't know what branches to follow. There was nothing interesting about the implementation of Deep Blue. It would be like implementing the Internet by shipping immense hard drives around to convey information: brute force, unintelligent, and immensely successful at delivering throughput.
We process information much slower than CPUs (how fast can _you_ read Wikipedia?), but we know when to give up, we know when to follow an interesting path, we know how to move processing to the subconscious.
Think about playing chess. Each move, there's 30 branches to follow. If you have a million machines, you can evaluate about 2 moves ahead before parallelism runs out. If you have bad branch prediction, you'll follow all the wrong paths.
Humans beat machines at creative endeavors because computers don't know what branches to follow. There was nothing interesting about the implementation of Deep Blue. It would be like implementing the Internet by shipping immense hard drives around to convey information: brute force, unintelligent, and immensely successful at delivering throughput.
We process information much slower than CPUs (how fast can _you_ read Wikipedia?), but we know when to give up, we know when to follow an interesting path, we know how to move processing to the subconscious.
Sure, but it's the massive parallelism of the hardware behind "the mind" that allows a human to intelligently filter information quickly. Our serial conscious thought is in no way indicative of the amount of (parallel) processing that goes on behind the scenes in order to make a "simple" decision.
He gives it as a class? Any links, or footage...? There's nothing from his homepage. Too bad, his live presentation should be recorded.
Biology is very much a show-me science and I've always wondered about Society of Mind ... what's his proof?
I mean seriously, is it all just reasoned out? Is it like philosophy?
I mean seriously, is it all just reasoned out? Is it like philosophy?
Ya know what, I dunno why you guys are all philosophising about all this stuff, as opposed to just having it BUILT ALREADY. I mean really, what does it take? So you take the ATX motherboard design, and scrap it. It's crazy old anyways. And if you can grow, or create graphene in a controlled environment, WHY does the graphene have to be a "CPU only" material? Why not use it for RAM, GPUs, and Cache??? I mean really.
And this is what I want to know... WHERE is Intel in all of this. THEY are the major chip-maker of planet earth. It's not like they don't have the money to build a new architecture for graphene. It's not like they can't build a proper fabrication plant. So WHY isn't MIT working with Intel on this one...? Duh.
This seems entirely uninteresting for CPUs since there are all sorts of issues with regard to that. However, THz frequency signals have all sorts of other uses
(http://en.wikipedia.org/wiki/Terahertz_radiation)
I'm thinking, even if we had infinitely fast CPUs, we might not gain so much because it would just reveal other bottlenecks. Not that I'd mind having an infinitely fast CPU...