Hacker News Reader

>Now that the cost of wafers are going up, making a chip that is 50% better costs 50% more money.

This is not true. In the past, process optimization was straight forward: Make smaller transistors. The free ride ended with the 130 nm node more than ten years ago. Since then, manufacturers had to introduce new features to allow them to make transistors smaller. As you also noted, this leads to higher costs, and the economics did not scale proportional to Moores law anymore.

But: This has been going on for more than a decade. The technology did not fall off a cliff and it will not do so in the near future. Even if it is not possible to make transistors smaller, it is still possible to introduce new technological features to make them better and improve their area efficiency. There are still plenty of options, even without classical scaling aka Moores Law.

TL;DR: Nothing will go poof. We are going to see a less steep gradient, but this is part of a process that started ten years ago.

We'll see this year when the new process pricing comes out. The specific claim was not that the cost of the wafer is higher but that the $/transistor price is the same or worse for the new processes. If that holds true, then you're done with scaling by process shrinks. (Intel doesn't publish those costs of course but both Global Foundries and TSMC do)

   > But: This has been going on for more than a decade.
   > The technology did not fall off a cliff and it will
   > not do so in the near future.

If by this you mean that the $/transistor has been going down more slowly over the past decade, then I agree with that. The question is if that number will stop going down, and/or go up this year. That isn't a 'cliff' that is an inflection point, or perhaps a global minimum.

When that minimum is reached, the economics of the 'computer' business (scare quotes because I'm specifically referring to what is known as the PC laptop/desktop business) will change fairly dramatically.

>That isn't a 'cliff' that is an inflection point, or perhaps a global minimum.

No, there may be an inflection point in the metric "cost per standardized transistor". But this does not equal "cost per function".

There are manys way to utilize transistors more efficiently or still make them smaller while performing the same function. You have to realize that not all transistors in a chip are of minimum size due to circuit design requirements. Furthermore, only a fraction of the transistors are actually involved in performing the logic function you see from the outside. There is an increasing number of transistors spent on "housekeeping" functions such as clock distribution, power gating, bus drivers etc.

All of these can be improved by working on circuit design, improved layout software, optimzing the materials in the transistors etc. Of course this is less straightfoward than simply making the transistors smaller and therefore more expensive. Therefore we are going to see diminishing returns, but there will not be an inflexion point in the business model of the entire industriy.

Maybe we're talking about different things.

You wrote this: "No, there may be an inflection point in the metric "cost per standardized transistor". But this does not equal "cost per function"."

I claim that is does equal cost per function. Here is my reasoning on that, perhaps we can find out where we're disagreeing.

I'm going to claim that an engineering group E has a design D which they put on a process node Pn. That is a pretty easy claim since pretty much everyone who builds chips does that. :-)

I'm also going to claim that the engineering group is doing everything they can to efficiently use their transistors based on the evidence that efficiency is a key sales metric for chips today.

Then I'm going to claim that for a given design D, on a given process node Pn, you can compute an average cost per transistor for that pairing by considering the number of transistors in the design, the number of instances on a wafer, and the yield of good devices from that wafer, divided by the cost of that wafer.

Here is the assertion the article makes (and I agree with)

In the next process shrink, the cost of producing a wafer will be so high, there there will be zero change in the cost of chips produced on that process.

The engineering teams will do all they can, but the wafer costs will be so much higher that the cost per chip will either not change or go up. It will track signedness if not in magnitude this metric of 'cost per standardized transistor'. Once that is shown to be true, there will be no more investment in new processes because the economic value will not be there. And I claim that this will mean that from that point on chips will get more expensive over time with or without additional features being added.

I can't wait for the papers from the 2014 ISSCC which will tell me if I'm crazy or not :-)

>Now the only way to make your machine faster and cost less is to write more efficient software.

Were still a long way away from that. Switching over to SSDs represents a huge speed boost, and given how young SSDs are, I suspect that there is still room for improvement in their speed. Also, there is likely improvements to be made in CPU architecture. We are still using x86, which has been improving incrementally with backwards compatible changes since the 70s. I'm not fammiliar with CPU architecture, but I suspect this means that there is room for significant improvements in terms of per transistor efficiency with the use of a novel CPU architecture. We could also see a drop in prices due to economical, not technological forces. For example, the price of a CPU is significantly higher than the cost to produce one. This is because you are paying for the development of the CPU. Without continuing fundamental improvements, we would expect to see the cost of CPUs fall to their marginal cost as development would no longer be necessary.

With the rise of iOS, Android, and ChromeOS which hide the CPU architecture completely from the user (especially when running Java or JavaScript applications), there are opportunities to change CPU architectures in more radical ways in the future.

But then again, the gains possible may be more limited that you suggest because the transition from x86 to x86-64 did involve a number of major efficiency gains from changing register counts and how FP calculations where done. There may not be huge efficiency gains left that are easy.

With LLVM basically being a new runtime in some cases, we can do more complex compilation strategies such as was attempted with the Itanium architecture: https://en.wikipedia.org/wiki/Very_long_instruction_word

Who knows... I'm just brainstorming today. Happy New Years!

The transition from x86 to x86-64 did not seem like a radical redesign of the architecture. The x86-64 bit chips are still capable of running code written for x86 chips without modification (even the 16 bit code I believe). Furthermore, the programming model (as exposed to assembly) did not seem to change between the two architectures.

As far as architectural improvements for increasing single-core performance go, we've already reached somewhat of a dead end. Intel x86 chips already do crazy things like rearranging instructions and executing 3-4 instructions at a time. With stuff like multi-core and SIMD now, we'll need compiler improvements to take advantage of the architecture improvements.

Not that compilers don't already make these optimizations. But it's pretty hard to map sequential languages like C to a many-core processor with really large SIMD units. Any abstraction that tries to make code still look sequential even if it is being executed on many cores is going to be leaky.

> I suspect this means that there is room for significant improvements in terms of per transistor efficiency with the use of a novel CPU architecture.

I seem to recall a comment a while back from an Intel chip designer guy saying that the x86 tax isn't as high as people think. Sure, the instruction set is super-crufty, but according to this guy they had found ways to implement most of the backwards compatible stuff in a way that's transistor efficient. He may have been biased, but didn't think the overhead compared to ARM was too significant.

I tried to google for the comment but couldn't find it, apologies for that. If someone with direct processor design experience would chime in that would be great.

"is to write more efficient software. Think about that carefully. It will define success in this next decade."

But optimization is the root of all evil... or something.

Knuth's saying goes "Premature optimization is the root of all evil." Which is just another way of expressing the Unix ethic of first make it work, then make it fast.