LWN.net Logo

GCC and static analysis

GCC and static analysis

Posted Apr 29, 2012 10:45 UTC (Sun) by khim (subscriber, #9252)
In reply to: GCC and static analysis by paulj
Parent article: GCC and static analysis

Nit: Wasn't it quantum tunneling effects and resultant current leakage that killed the MHz war?

Nope. These can and do limit speed - but this limit is near terahertz. Worse: this limit have not stopped growing in the last decade: it went from about 100MHz to 800MHz+. Yet CPUs have stopped at 4-5GHz. Pentium4 was famously unable to reach this limit (fastest model reached 3.8GHz) while POWER6 (with it's entirely different architecture) stopped at 5GHz.

There are many different processes which limit the speed of CPU but they all are related to propagation of signals - and these are measured in fractions of speed of light. Refractive index of silicone is large (about 4, but, as usual, it depends on frequency) while refractive index of copper is low (about 1.10 - but, again, it depends on frequency). In the end the fact that at frequency of 100GHz speed can only pass 3mm in vacuum means working CPUs can not be built at this frequency.

Note that frequency of x86 CPUs is still incresing - but at totally different speed. Nehalem reached 3.86GHz at 45nm (Core™ i5-680) while Sandy Bridge reached 4GHz at 32nm (Xeon® E3-1290). You may say that it's limited by thermal envelope (as current leakage will predict), but I'll just point out that Core™ i5-680 is dual-core CPU while Xeon® E3-1290 is quad-core CPU. Where is my single-core 6GHz CPU? I know a lot of guys who'll be ready to pay good money for such a beast.


(Log in to post comments)

GCC and static analysis

Posted Apr 29, 2012 18:11 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, there are asynchronous chips that can work without clocking entirely.

They are easy to create for low 'frequencies', but it becomes harder and harder to design them as you increase their complexity. However they are not limited by the lightspeed.

We still have a lot of way to go. Probably, we'll reach at least 20-30GHz with carbon-based transistors.

GCC and static analysis

Posted Apr 29, 2012 18:21 UTC (Sun) by apoelstra (subscriber, #75205) [Link]

A light-nanosecond is roughly 30cm (or roughly a foot, if you'd like). So at 1Ghz, light in a vacuum can reach 30cm per tick. Electrical signals in copper travel at around (1/3)c can reach 10cm.

(I find it very funny that we can use such nice numbers, given that both the meter and second were defined long before c was known.)

So at 20Ghz, this is cut to 5mm. In other words, your die can have a diameter of at most 5mm, no matter what crazy architecture you can imagine, if you want the processor to function at 20Ghz. So in a space of (5mm)^2, you're sending 20 000 000 000 signals per second, which need to be much stronger than background noise.

This does not sound possible to me.

GCC and static analysis

Posted Apr 29, 2012 18:28 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

>A light-nanosecond is roughly 30cm (or roughly a foot, if you'd like). So at 1Ghz, light in a vacuum can reach 30cm per tick. Electrical signals in copper travel at around (1/3)c can reach 10cm.

Yep, I have one nano-lightsecond length of wire in a frame on a wall at home (it is a gift from a friend who got it from Admiral Grace Hopper herself).

>So at 20Ghz, this is cut to 5mm. In other words, your die can have a diameter of at most 5mm, no matter what crazy architecture you can imagine
Why? Async chips do not depend (strongly) on the speed of light. One part of an async chip can be doing completely unrelated tasks. Of course, in the end you'll hit the lightspeed wall, but it's a long way off.

>So in a space of (5mm)^2, you're sending 20 000 000 000 signals per second, which need to be much stronger than background noise.
So? Modern network routers work at about the same speed and die size.

GCC and static analysis

Posted Apr 30, 2012 15:10 UTC (Mon) by khim (subscriber, #9252) [Link]

Why? Async chips do not depend (strongly) on the speed of light.

Async has huge PR value (you can claim you chip is working on 100GHz or even 1THz if you are lucky). It does not change anything WRT to actual speed of computation.

One part of an async chip can be doing completely unrelated tasks.

It's the same with synchronous schemes as well. Why do you think Prescott had over 30 stages in pipeline? Why do you think Itanic has L1, L2 and L3 caches - all on the same chip with the same semiconductor process technology?

Of course, in the end you'll hit the lightspeed wall, but it's a long way off.

In the end the nominal number on the CPU envelope is just a number. Sure, you can create totally-async 1THz chip which will need "about 1000 tics" to add two numbers together, but it'll be slower then Core i7 so what's the point? Lightspeed barrier it as real for async as it's for traditional CPU.

Note that lightspeed barrier only limits latency (of single-threaded program in this particular case), it does not affect throughput at all. In fact a way to create tremendous throughput is well known: just use more of the same things!

So? Modern network routers work at about the same speed and die size.

They don't execute sequential program, that's totally different kettle of fish. For them streaming async design makes perfect sense. For GPUs it can be applied, too. For CPUs? Not so much. Netburst tried to do that. It failed. I doubt anyone will actually try to do it again.

1mm cube?

Posted May 5, 2012 3:28 UTC (Sat) by gmatht (guest, #58961) [Link]

If thermal density wasn't a problem, we should be able to fit lots of 22nm transistors into a 1mm cube.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds