Hacker News new | past | comments | ask | show | jobs | submit login

> ... a nanotube based transistor would be able to switch 70 times as fast as a silicon based one. Or a quarter of a terrahertz, in other words.

A transistor switching at 250GHz would not be 70 times faster than a silicon transistor. In fact, it would only be a little over 2x faster. Our best production quality silicon transistors are well over 100GHz now.

The clock frequency of a CPU is not the speed that a single transistor in that CPU switches. It's the speed that the longest path of transistors inside a single pipeline stage in that CPU switches. In contemporary CPUs, these paths are ~20 FO4¹ long.

(¹ since the speed of the transistors depend on the load put on them, you need to normalize for that. http://en.wikipedia.org/wiki/FO4 )




You're entirely right that I misspoke there. I meant that the clockspeed for similarly architectured devices would go up to a quarter terrahertz, but I managed to imply something entirely different.


No, it really wouldn't. Clock speed is as much restricted by light speed delays as it is by transistor switching speed.


Ok, I'm going to disagree with you here. Speed of light delays cause latency when you're talking about large structures like caches, but they're not even the biggest factor in L3 with current processes. If we were clocking things as fast as nanotubes allow then we probably would find speed of light delays dominating latencies, but increased latencies will only eat a proportion of the gains from higher clock speed, and that's what we have branch predictors, prefetchers, and deep OoO engines for.

Unless you were talking about clock skew between the exit points of your h-tree?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: