DARPA Looks Beyond Moore's Law

ddtstudio writes "DARPA (the folks who brought you the Internet) is, according to eWeek, looking more than ten years down the road when, they say, chip makers are going to have to have totally new chip fabrication technologies. Quantum gates? Indium Phosphide? Let's keep in mind that Moore's Law was more an observation than a predictive law of nature, despite how people treat it that way."

Comments

What about diamonds?

[GreenCrackBaby]

This diamond article in Wired 'http://www.wired.com/wired/archive/11.09/diamond. html' seems to indicate that Moore's law is sustainable for much more than ten more years.

Besides, I've been hearing about the death of Moore's Law for the last ten years.

Get rid of C!

[Temporal]

Not many people know it, but one of the problems holding back processor technology today is the way programming languages are designed. Languages like C (or C++, Java, Perl, Python, Fortran, etc.) are inherently serial in nature. That is, they are composed of instructions which must be performed in sequence. However, the best way to improve the speed of processors is to increase parallelization; that is, make them do multiple things at once. And, no, threading isn't the answer -- threading too large-scale, and can only usefully extend to 2-4 parallel processes before most software has trouble taking advantage of it.

Think about this: Why is video graphics hardware so much faster than CPU's? You might say that it is because the video card is specifically designed for one task... however, these days, that isn't really true. Modern video cards allow you to write small -- but arbitrary -- programs which are run on every vertex or every pixel as they are being rendered. They aren't quite as flexible as the CPU, but they are getting close; the newest cards allow for branching and control flow, and they are only getting more flexible. So, why are they so much faster? There are a lot of reasons, but a big one is that they can do lots of things at the same time. The card can easily process many vertices or pixels in parallel.

Now, getting back to C... A program in C is supposed to be executed in order. A good compiler can break that rule in some cases, but it is harder than you would think. Take this simple example:

void increment(int* out, int* in, int count)
{
for(int i = 0; i < count; i++)
out[i] = in[i] + 1;
}

This is just a piece of C code which takes a list of numbers and produces another list by adding one to each number.

Now, even with current, mostly-serial CPU's, the fastest way to perform this loop is to process several numbers at once, so that the CPU can work on incrementing some of the numbers while it waits for the next ones to load from RAM. For highly-parallel CPU's (such as many currenty in development), you would even more so want to work on several numbers simultaneously.

Unfortunately, because of the way C is designed, the compiler can not apply such optimizations! The problem is, the compiler does not know if the "out" list overlaps with the "in" list. If it does, then the compiler has to do the assignments one-at-a-time to insure proper execution. Imagine the following code that calls the function, for example:

increment(myArray + 1, myArray, count);

Of course, using the function in such a way would not be very useful, but the compiler has to allow for it. This problem is called "aliasing".

ISO C99 provides for a "restrict" keyword which can help prevent this problem, but few people understand it, even fewer use it, and those who do use it usually don't use it everywhere (using it everywhere would be too much work). It's not a very good solution anyway -- more of a "hack" if you ask me.

Anyway, to sum it up, C generally requires the CPU to do things in sequence. As a result, CPU manufacturers are forced to make CPU's that do one thing at a time really, really fast, rather than lots of things at the same time. And, so, since it is so much harder to design a fast CPU, we end up with slower CPU's... and we hit the limits of "Moore's Law" far earlier than we should.

In contrast, functional languages (such as ML, Haskell, Ocaml, and, to a lesser extent, LISP), due to the way they work, have no concept of "aliasing". And, despite what many experienced C programmers would expect, functional languages can be amazingly fast, despite being rather high-level. Functional languages are simply easier to optimize. Unfortunately, experienced C/C++/Java/whatever programmers tend to balk at functional languages at first, as learning them can be like learning to program all over again...

So, yeah. I recommend you guy