I don't think the original does. That follows, though.

If you're fitting twice as many transistors into the same space, then the same chip design using the new process will cost about half as much because you can produce twice as many per wafer.

Yet usually that's not how it works, because there are new processor designs that use more transistors by the time the process change comes about.

If you're fitting twice as many transistors into the same space, then the same chip design using the new process will cost about half as much because you can produce twice as many per wafer

You're neglecting the fact that smaller structures need purer "raw" material, which implies much more preprocessing.

Also this calculation only works as long as you can get lamps with sufficiently short wavelengths. If you can't anymore, you have to resort to electron beams, which are slooooow.

To turn a tiny bit more on topic: this a good example that you can't just stop thinking at one abstraction layer, which we recently discussed in another meditation ;-)

In the late 90's Moore revised his prophecy to saying that he expected the number of transistors to double every 2 years.

In a 2000 interview with U.S. News & World Report, Moore said that he expected this rate to hold for another 10 to 15 years.

Sure. Algorithms can matter. But, they only do so now when dealing with large datasets

But "large" depends strongly on the algorithm.

I remember reading a node here (can't find it, sorry) about a regex taking exponential time matching some piece of HTML.

For an algorithm that needs exponential time a line of 80 chars can be long. Really. In 10 years that limit might be 100. Or 120.

Typical examples are the knapsack problem that appear in real world applications over and over again, which takes exponential time when solved with brute force. Approximation algorithms can solve it much faster, even if a bit inaccurate.

I'm sure even you would argue that you should optimize when a O(2**n) code hits you.

But if you normally don't optimize, you have no feeling for what is slow and what isn't, don't know about profiling etc. Which is why I do optimize my applications from time to time.

BTW a real world project that has been hit by missing optimizations recently is the KindaPerl6 compiler, which was so slow during bootstrap that it just wasn't practicable anymore. It took the fun out of the development process, and now I haven't seen a single kp6 commit since... lemme check... 2008-03-16. (Surely this wasn't the only problem, but IMHO it was the one with largest impact).