Hacker News Reader

Comment by dmarcos | Hacker News Reader

I've been following the semiconductor news in the last year closer than ever before. It really feels that the 7nm node will be the end of Moore's law. As a software engineer it intrigues me the constrains is going to impose to our craft in the next decade. We've been riding the performance exponential growth that allowed us to be sloppy programmers and still produce increasingly complex software. I work on the VR space and the conventional wisdom is that headsets and GPUs are going to get drastically smaller and powerful every year. I think this is not a given anymore and as a software practitioners we will have to step up the game and be much more careful about using resources. How is the end of Moore's low going to affect the cost of Software Development? The top software companies will be those that best use the hardware. Performance optimizations usually makes software more complex and increases the rigor you operate in. Many people have been able to got from 0 to make relevant contributions after learning programming in a few months or going through a coding bootcamp. That might get harder and harder since you will need deeper knowledge to produce competitive software. Is this going to increase the barrier of entry for developers? Is the developer pool going to shrink? Salaries go up? Is it going to be more a and more expensive to produce competitive software? Will it make software startups more capital intensive, since gluing 4 pieces of existing code around a good idea won't be enough to be successful?

View on HN

The interesting thing is going to be the potential for "free as in speech" hardware. Before the problem was that hardware was vertically integrated. If you wanted a state of the art processor you had to use a design from a company with a state of the art fab because nobody else had the resources and inclination to update their design for every new process node.

If we get to the point that TSMC has the same technology as Intel and IBM and it never changes then some hardware hackers will eventually publish something like a 250MHz processor that uses 10 watts on that process, which will be "good enough" for some embedded devices to justify a fairly large production run. Then you have a community and people make incremental design improvements for the same reasons Google and others do for Linux and in a few years the free hardware design is above 2GHz and below one watt.

Isn't this was raspberry pi is?

Raspberry Pi does not use open source hardware. The processor core (ARM) is proprietary. The GPU (VideoCore IV) is proprietary hardware, and even includes proprietary software in the form of microcode. And so on and so forth.

Open source hardware refers to the silicon itself using open source designs.

Indeed, Broadcom doesn't even allow you to buy their proprietary SoC (at least, last I checked), so you can't make a knock off RPi board, or integrate the SoC and peripherals into a custom application board. You need to use an RPi directly or get some other Cortex-A53 chip with a comparable architecture.

Open source hardware refers to both the system level design and the IC level design. Credit where it's due, Raspberry PI is open hardware on the system level. You are right that it is not open on the IC level.

Nonsense. It's not open at any level by normal definitions (although some of the software is open source). The Raspberry Pi is a wonderful thing. It's cheap and it works great...but it's not open.

The VC4 GPU is a lot worse than microcode! It's running the complete (proprietary) ThreadX operating system, regardless of what you choose to run on the ARM core.

You meant VPU, not GPU? The GPU is fully open.

Yes, I called the VC4 the GPU because the parent post (and many other resources) call it a GPU. But yes, it is the VPU.

No, but it is what RISC-V is! I'm really excited about RISC-V after reading Andrew Waterman's PhD thesis[0] on it from earlier today.

[0] http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1....

Will the US allow something like that happen? The future is developing towards hardware backdoors in all processors and this would make it really hard to implement such system. There is no way this is going to happen.

I really doubt that's going to happen given that I've been pushing various parties to do it who have skills, EDA tools, and some academic funding. And it's still not done.

My advise is still the same, though: put Gaisler's Leon3 SOC w/ key I/O on fab at 180nm-90nm using shuttleruns like Tekmos. Its been GPL with no action forever. Already has OSS software on it, too. SPARC compatible trademark only costs $99 if you wanted to be official.

So, if there's such a will or demand, where's our open-source SOC that uses Leon3? It's been one MPW, packaging, and PCB run away forever. Still don't have one...

Not sure I see what the purpose of taping out Leon at 180nm? Is it just to have an open source CPU? Hardware is only useful if it's competitive.

The parent was satisfied with a low-performing chip that was fully open. There's a niche of people that want fully-open, inspectable hardware they control totally. I keep calling out proponents with Leon given they've been able to accomplish that at 350nm w/ visual inspection and 180-130nm affordably at least with OSS HW. Plus, there's quite a few open, cell libraries at 0.13nm.

Anyway, you know what I wanted: open-source, 28nm FPGA w/ key I/O already included so I could synthesize my own CPU's and such on it. Verify one design in hardware, worry about the rest in simulation. You never got back to me on that one. Whether it was a good idea to solve most people's open-hardware concerns or what it might cost?

(I'll say a Virtex-6 amount of slices or memories with USB 2.0, DDR3, PCI-E, SATA, and 10/100/1000 Ethernet onboard. Should do.)

We might not need full trust. We could just add a secondary processor isolated from the system which can run encryption and store its keys inside, like the iPhone does, but one that we are sure is not corrupted. Maybe the security processor could also run a firewall to filter out which app can communicate what.

I believe you are correct as well and they mention Moore's Law being broken in the article[1]. Silicon at least is pretty much done for. And if their cost estimate of over a quarter billion to do an SOC in 10/7nm is accurate you won't see very many interesting "side" projects on that node, those will all live on 28nm at $30M/project.

But the more interesting effect for me has been that Moore's law has slowed down but the exponential growth it had given computers allowed them to speed past even our more amazing ideas. We haven't reached Jim Gray's "smoking hairy golfballs"[2] yet but we also don't upgrade our machines nearly as often. When I bought a new laptop, I bought it for its stylus experience, before that I bought a new lap top for its retina display, and two years before that was the last laptop I had purchased because the one before it wasn't powerful enough to do the stuff I needed to do (most e-cad, m-cad, and code development)

So how does the world change? Some software places might consider writing software that doesn't change for change sake. Every year my m-cad vendor wants me to upgrade to the latest version and every year its the same story, tweak here, bug fix there but no new features. Support for new things the OS has imposed sure, but not real features.

This has been great for Linux folks, where the same computer has been fine for 5 - 6 years now. They can look forward to actually seeing a computer fail due to old age rather than forced obsolescence. It will be harder to maintain a distro that runs on a decade's worth of hardware changes. And that latter is the killer.

So computers aren't changing but as I mentioned before the I/O around them is, better screens, better peripherals, different ways to do storage. Since that is the only way to force upgrades these days, I expect to see a lot more of that.

[1] From the article -- “Because Moore’s Law has broken down and you no longer get gains in all areas at the same time by going to the next node, each foundry customer will have a different strategy, depending on which parameter is most important,” according to a source at one large customer, who asked not to be named.

[2] http://research.microsoft.com/en-us/um/people/gray/papers/Su...

> So how does the world change? Some software places might consider writing software that doesn't change for change sake.

Inconsequential feature creep doesn't happen for changes sake, it happens because people want to keep making money.

Well, when the performance cost of those features can no longer be waved away easily as something most people won't have to deal with sure to faster hardware, they may need to come up with some different ways of making money, or at least put some more thought into the current strategy.

I would like to point out that not all ideas have been outpaced by Moore's Law, some obviously hit serious blocks after the barrier in the early 2000s was hit and caused the invention of multi-core on consumer machines.

That I can personally attest to:

1. Simulation games are mostly stuck in power available since the 2000s, many common game algorithms can't be made parallel, and several algorithms increase in computing cost faster than processors increased in power since then (example: Astar, its computing cost rises quadratically with the search space, and the search space when you want to increase a game map size ALSO increases quadratically, thus to double a city simulator map size, you need to run A* 8 times the processing power... if you pay attention city simulators since SimCity 4 release tended to make instead smaller maps with more miscellaneous simulations).

2. CAD, CAE, etc... In this case the recent advances, including in GPU design made those software much faster, but they are still rather slow, if you need to compute a complex project, or even a simple project with greater precision, you still need some crazy powerful computer... As personal anecdote: I am trying to design a PC case for myself, decided to try my hand with CFD, first to test I made just a empty box with a "fake" fan, that is just a number saying how much air get inside the box... got a good result in 3 minutes. decided to test what happens if you have 4 fans side by side... well, this creates turbulence, thus need a more detailed grid to calculate that, the grid generation alone took 20 minutes, I decided to make half-assed simulation and the result was mostly nonsense. I decided then to test if I could model the entire fans, including their blades, housing, etc... I got a already done precise model of a fan, tried to generate a grid... and my computer overheated after 5 minutes using an i7 at 100% Of course, I knew I was "abusing" things, still, it became obvious to me that CFD for example, for anything "serious", is mostly impractical, if I had infinite money, I would still need to setup some kind of huge cluster or super computer, and the code to run CFD in that would be very complex, the thing is possible, but still impractical, even with infinite money.

Their figures for chip costs at all nodes are bullshit including the $30M/chip at 28nm figure. It's inflated out of all proportion and of course it depends tremendously on what you are doing.

Interesting. Could you please give more accurate examples, and maybe a rough breakdown between masks/tools/front-end/back-end ?

Adapteva has done chips for <$2M AFAIK, definitely <$5M, at 28 nm. Of course few chips are like theirs in terms of design simplicity relatively to their large size except for bitcoin miners. For $10M however you should be able to do pretty big designs with lots of licensed IP, heavyweight simulation acceleration etc. A breakdown of real projects involves violating NDAs.

Below 28nm their numbers become really deranged. This overstatement is IMO peddled by big name chip companies trying to convince analysts that FinFET nodes give them a moat. In reality the end of Moore's law means they'll face vicious competition.

Of course nothing prevents you from spending huge amounts of money. Buy an ARM architecture license - there goes $30M and that's before you pay for developing your own ARM-compatible CPU.

Yosefk, thanks for pitching in and fighting the complete bs that gets flung around regarding chip design costs. Some of these projections are just ludicrous, clearly made by people who are not currently involved in chip design.

For argument's sake, let's pin the tapeout cost at $5M and EDA costs at $1M. Everything else is engineering. The reason these projects are expensive is that the chips are complex (because the have 10B transistors!). It has nothing to do with technology scaling (except for the fact that smaller nodes lets you integrate more transistors). I can design a memory chip (with repeating structures) in any node for almost nothing (..besides the tapeout cost). If they would have costs have escalated from $50K at to $5M at 14nm, that would be reasonable. The $250M number is utter nonsense....

Some more background:

http://www.adapteva.com/andreas-blog/semiconductor-economics...

The other comment to yosefk is mine citing your Lean Fabless article to contradict the point you just made slightly. Feel free to clarify on that if I'm misinterpreting something. Yet again, your next link supports "ludicrous" prices if it's a complex, full-featured SOC along lines of Apple products. Perhaps they should put qualifiers in these articles to be clear they're talking about high-end stuff with big numbers of parts and engineering required. If they even know what they're talking about.

Yet, two of your articles suggest me doing a Snapdragon or something without buying third-party I.P. or RTL could easily cost the numbers in the article on 28nm. Or the other nm. Intended audience of those big nodes will also mostly be companies making stuff like that where they can afford development costs. Do shuttleruns even exist for 16/14nm?

You're talking about this:

http://www.adapteva.com/andreas-blog/a-lean-fabless-semicond...

Adapteva is pretty clever. Yet, they don't tell us whether they reached $2 million at the 16-core model with 64 costing much more or if that was both. The write-up also says they used third party I.P.. It implies they outsourced as much stuff as possible. You can bet it was mostly standard cell rather than custom in those. They used the shuttle runs I often advocate which are available on their chosen nodes. Biggest part, they recovered this by selling to niche markets that didn't care much about price. Try that in mass market outside being Apple you will fail.

All quite different than doing a whole SOC by yourself on 28nm. They even admitted complex SOC's can cost big money:

"Complicated SOCs are indeed very expensive to develop and there are few if any examples of complete products that have cost less than $10M from start to finish. "

So, now we've shifted from $2mil to $10mil that quickly. Gotta wonder what in-house development of full SOC a la Snapdragon with bells and whistles at 28nm costs with only packaging or PCB's outsourced. Is it maybe $10-30 million? ;)

We can't tell you the detailed costs because this would violate our NDAs, but until our 2011 28nm tapeout, we had raised less than $2.5M in capital and taped out 4 chips at 65 and 28nm.

There is no mystery here. EDA costs, tapeouts, engineering costs are all known. Tell me the chip you want to build, I'll tell you how much it will cost.:-)

People seem to have a hard time grasping that the term "SOC" is meaningless when it comes to predicting cost. It's like comparing the cost of a Ford Focus and a Ferrari. Sure they are both cars...

Thanks for the clarification. That's hopeful. I just gave you a sample question on cost in another comment. Even a range will be helpful when soliciting academics on it.

I provided ranges in the paper. To focus in further, you will need to get actual quotes from vendors. This is because the price is completely opaque and depends on circumstances.

http://www.adapteva.com/andreas-blog/semiconductor-economics...

Oh damn. I figured it wouldn't be that easy. Thanks anyway as your write-ups have been helpful. I imagine the chip-to-chip interconnect might be, too, at some point. :)

Were your tapeouts shuttles or full production tapeouts?

Until 2011, all of our tapeouts were shuttles. (for our initial market the per die cost was fine). You get 50 dies/wafer on a shuttle run and can order a lot of wafers...with a theoretical per wafer price of $5000 that would mean $100 die, which is not bad for some systems.

Full mask tapeout was done later.

What shuttle service did you use for 16 and 64 core development? Might help someone stay close to your cost profile. Btw, your data sheet for 64 core says 65nm, too. I thought it was 28nm or maybe I misread one of your posts. 16 to 64 core on same node would be nice. :)

And good luck with "The Brain." Saw that on your website just now. Funny that I was thinking of proposing to someone a prior product for revival that did NN's with 256 8-bit cores on 0.5 micron with good results. Then, ABC Thinking Machines Super-Connector had badass GA results back in the day with 64,000 simple cores. Your design looks like a Thinking-Machine-on-a-chip level of cores with cores being more versatile. Not 64-65k but close enough. :)

You might find this interesting:

https://www.synopsys.com/dw/ipdir.php?ds=ev52-ev54

This.

Also, the design man-hours quoted in the article must be when designing from scratch, and may or may not be accurate. In the context of moving to a new node and iterating on a previous design, the quoted numbers are junk.

> you will need deeper knowledge to produce competitive software

Alternative theory: there will continue to be bad programmers, but there will also be good money in compilers that can deal with it and turn crap into optimized goodness. Midas compilers.

I also suspect a few new language concepts (like Rusts ownership model) will need to be invented as well, to enforce certain optimizations with minimal cognitive load on the developer.

> Alternative theory: there will continue to be bad programmers, but there will also be good money in compilers that can deal with it and turn crap into optimized goodness. Midas compilers.

No amount of compiler optimization is going to fix algorithmic failures.

Depends on what limits you place on the definition of 'compiler'.

Optimizing via better algorithmic choices is a semi-deterministic process performed by a human. Why can't a computer do it too?

Code is just your way of telling the computer your intentions. Once it can understand those deeply, well, it can choose a better way to achieve those intentions.

This has already happened with SQL databases. Performance tuning a database can be messy because sometimes you have to outsmart the query optimizer. But in the average case it is doing the Right Thing without you having to think about what engineering has gone into it.

Demand for new data models is insatiable and for each one, a software ecosystem can develop around a similar degree of automation, tuned towards the specific domain. It's a very, very black-boxed future.

To some extent the mobile platform did the same thing:increasing the constraints, both on performance, and on interfaces. So maybe we'll see something similar ? more demand, higher salaries, but non the less, options for relative noobs to do interesting things ?

"Nonetheless", ftfy. Sorry for nitpicking.

I'm actually of the opinion that when we can't scale smaller we will then scale horizontally/laterally.

More transistors, larger chips.

We have bought so much physical space going smaller and smaller - and I think a lot of people will happily pay for a thicker iPhone if it's not more room allocated for a larger battery.

Eventually - when that becomes ridiculous - we will write better software. More likely we'll buy an extra couple years after the end of Moore's Law and Intel will make some unexpected breakthroughs to go smaller again.

Color me cynical?

1 word. Heat.

Intel had to work their ass off to get them out of the ditch they dug for themselves when pursuing insanely high clock speeds in the Pentium 4 era.

This heat problem can be solved if they make it a priority. Until now they've been able to get away with ignoring it as new nodes have kept them competitive. If that changes, which it is, a new approach is required.

Another words to add : yield/cost

7nm is not the end of Moore's law. The whole reason why there are problems now is because they are switching from paradigm. ASML is the largest supplier of photolithography systems and has been upgraded from 32 nm to the next 10 nm.

However, as the new EUV machines are being put into production. It does not make financial sense to still make the 10 nm chips. As buying the new machines and infrastructure is a huge investment, you can understand that some companies are focussing on the existing 10 nm machines (maybe focus on lower end of the market). The problems with EUV are mainly starting problems with using different technology, IBM has already made 7nm chips and ASML has 5nm and 3nm in their roadmap[1].

[1] http://arstechnica.com/gadgets/2015/07/ibm-unveils-industrys...

[2] http://www.computerbase.de/bildstrecke/61547/2/

Honest question: what's in the cards for after 2022? That's only 8 years away. How can the trend continue for another 50 years?

> Is this going to increase the barrier of entry for developers? Is the developer pool going to shrink?

I don't think we are going to see that. Most use cases are not performance constrained (ex: a simple app or website). What you're talking about applies to cutting edge graphics, machine learning, OS and compiler design and a few other computationally intensive domains. Our computers are going to be at least as fast as those of today, so they will be able to run even the sloppy software of today with no problem other than (maybe) excessive power usage.

I think we are going to see an even greater shift towards asynchronous and parallel programming and design of specialized hardware for speed and low power. Also, we're going to have a much more complete AI toolbox than today, containing ready made image, video, audio, text, dialogue and behavior modules. For example, there is no need to reinvent the wheel when we already have a neural net that can distinguish tens of thousands of objects. Once it's trained in one place, it can be easily copied and run everywhere else, like an app.

Performance per dollar may still rise, when existing processes are made cheaper. But, I think for software it's clear that parallel processing is the way forward, and it impacts developers who need to upgrade their skillset, and language and tool makers, since just offering threads and locks and leaving the problem of scaling to the developer just won't cut it.

I've been doing a project that's a combination of java play, with its NIO and actor model approach to parallellism, and apache spark, with the rdd approach. Either solution lets you scale horizontally without having to manage locks and threads yourself and I like both approaches, but you can tell it's still early days. These approaches need to mature, standardize, and then percolate throughout all languages and frameworks, but eventually they will and we will be writing parallel code by default.

That's an idea I've been thinking about. But I have a few responses that have been bouncing around my head on that topic.

- Do we need much faster hardware for most tasks people are actually trying to accomplish? I don't think software is necessarily becoming more complex. It could be simplified it's just rushed out the door. I think complexity has plateaued. A common run of the mill usecase of application-layer software, a CRM, isn't limited by CPython (and definitely not by PyPy) today and there's no reason why it would start tomorrow.

- Something new will come along for hardware. So it actually is inevitable it moves forward. This isn't anywhere near the end. It may stratify hardware. If you truly need more performance, it may be very expensive hardware. The rest of us will rely on servers running on 7nm chips for ages. In connection to this point, the machine I'm typing this on is from 2009. A Q9450, it's still more CPU processing power than I need. I think that says a lot. The only reason I want to upgrade is for less power draw because that means less heat produced. If I needed more power for video, 3D rendering or compilation I'd use networked processing which would annihilate any local big iron I could put up in my basement.

- More development platforms will dump everything that isn't LLVM based. Significant gains could be had if say, Python was reimplemented on top of LLVM.

- For cases where the everyman company needs more power, they won't go for the chips made out of brain tissue or diamonds. They'll use services like AWS to gleam the power needed which will have the more expensive hardware on-top or massive swaths of 7nm CPUs to utilize.

- Chips will increasingly be built for specific tasks. Dropbox will keep having custom designs built by Intel for their specific workload. The general-use CPU will become less popular in the server room but still there for the small to midsize companies to lean on.

So while there's some individual points there, to add the always beloved car analogy. I've downgraded my car from a 325HP model 10 years ago to a 145HP model that I've been using since. Both got the job done within their environment and I suspect at worst, chips will simply become a commodity closer to modern day cars. The advance won't be more HP or better brakes, those are mostly maxed out in capacity. The paradigm shift is where the advancement will be (electrics for cars). But it's been settled for a while that either way, I really don't need over 150HP for what I'm doing.

The future is what was started with the old mainframes: general purpose CPU's plus I/O and algorithm acceleration. Possibly onboard FPGA logic. See Cavium Octeon III's w/ their accelerators, the Zynq line which Intel/Altera will likely do for Xeons, AMD's Semi-Custom business that took off, little GPU's in all the SOC's, and so on.

Good news is many accelerators work well at old 90nm and 45nm nodes based on my reading of academic papers. Even startups or FOSS projects can still get plenty of mileage out of the cheaper nodes. The Core Duo 2 I'm typing this on... still running ever bloated web well... was taped out on 65nm.

We'll see a lot more co-design of hardware and software. So far, outside of major trends (e.g. multi-core CPUs, GPUs), authors of different abstraction layers (programming languages, compilers, OSes, etc.) have worked towards improvements independent of other areas. I suspect that much of the improvement over the next 50 years will come clever tricks that require collaboration across more than one area.

Consider a simple example: CPUs have had caches basically forever. Caches are the epitome of independent development, because they require modest performance improvement with no effort. (Advanced users and compilers can of course put in more effort to get more improvement, but the maximum improvement is limited because CPU vendors have been reticent to allowing direct user control over the cache.)

What if these caches were instead scratch pads? Frankly, this sounds like painful way to program, especially in traditional languages, because now everything will have to be explicitly moved into the scratch pad. Maybe high-performance users will benefit, but the vast majority will not.

But we can reinvent the language as well. Let's propose a different programming model: tasks (blobs of code) with explicit data usage declarations. The rule is that a task only runs when its data is available. Thus the processor can copy data into the scratchpad asynchronously, and only run the task when all the data is there. Suddenly, there are no more cache misses! We just had to give ourselves permission to modify the programming model too.

Well, actually this is not a hypothetical programming model. I've described Legion, a programming system from Stanford [1]. A software-only implementation of Legion was able to scale to 1000s of nodes on a distributed system [2], so we know the basic approach works. Even better, the Legion folks described a type system which allows you to hide the gory details behind an easy-to-use apparently-sequential programming language [3, 4].

So far, these results have focused on software only. What would it look like if we were able to change the hardware as well? To answer your original question: I think this will require more expertise (and more diverse expertise) on the part of the system designers, but if we do it right, we can still design a system which is easy for everyone else to use.

That's where I think the biggest wins will be in the next 50 years.

(Disclaimer: I work on Regent, the Legion programming language)

[1]: http://legion.stanford.edu/ [2]: http://legion.stanford.edu/pdfs/legion-fields.pdf [3]: http://legion.stanford.edu/pdfs/oopsla2013.pdf [4]: http://legion.stanford.edu/pdfs/regent2015.pdf

Moore law is about number of transistors per chip (IC). You can make transistors smaller, you can make chips larger, you can stack chips and you can make integrated circuits from several parts.

I think your feeling is wrong.

If you care about miniaturization you can't make chips larger. If you stack chips you will have to deal with heat dissipation. What do you mean about making integrated circuits from several parts? I'm not an expert on IC design. The reality is that laptops have not increase performance in the last 5 years as much as they did before. Desktop GPUs are getting more powerful at the expense of being more and more power hungry. I feel that in the smartphone space the claim of "This new model is 2x performance of the previous one" will be harder to make.

re:desktop GPUs - AMD/NVidia stayed at 28nm for the last ~5 years. 14nm coming this summer to both.

What you are saying is PRECISELY why Moore Law ended with 7nm.

Mind you, performance improvements didn't ended, we can still find other ways to do things...

But 7nm is the smallest physically possible transistor (well, theoretically it is 5nm, but that one can't be actually manufactured).

So, you hit 5nm, then what? Your only choice would be make chips larger... but if you do that, you limit your maximum clock (example: a 5cm processor, if it allowed data to travel at light speed, and had perfect cooling, would still be limited to 6ghz)

Or make them taller, but then you can't cool them easily.

That is the problem, Moore Law, as in transistors per chip, ended with 7nm, there is nowhere to go after that, the only thing you can do is add more chips and make them communicate with each other (ie: multi-cpu... see what AMD has been doing in their recent research, trying to figure how to make an API to allow infinite amount of GPUs in the same calculation in a way 100% transparent to the developer).

But making more chips is not improving Moore's Law.

The only thing that can be done now, is invent something else, silicon transistors are done for, you can't improve them much anymore, you can only change the tech (use something else other than silicon transistors) or find novel ways to use current silicon tech (better architectures, multi-chip systems, better code, etc...)

>Or make them taller, but then you can't cool them easily.

Haven't you answered your own question? Your other points are about impossibility - the one I just quoted, about making chips taller, is about difficulty.

If I were the head of Intel I would say "Well. Hmmm. All right. I guess we'd better start making them taller."

Moore's law is not a question of "how hard can it be". As you've pointed out, on the current approach it's a question of "It is physically impossible for us to increase transistor count without dropping the clock rate or moving out of roughly a plane. No thanks to Einstein. (My favorite link on this subject: https://www.google.com/search?q=c+%2F+4+ghz )

You say "Or make them taller, but then you can't cool them easily." Well then, make them taller and cool them with difficulty. Nobody said it would be easy. Off-hand you could:

-> Immerse the taller chip in insane cooling

-> Fabricate little duct work between layers and liquid cool at high velocity

-> Figure out a way to reduce heat waste usage, e.g.: different substrate, not silicon (pretty insane)

-> Possibly combining some of the above points, make it a superconductor.

These are insane ideas from me. But then again, I'm not the head of Intel and you've heard a few minutes of thought on me on this topic, where I'm not a chip designer.

"When you have eliminated the impossible, whatever remains, however [difficult], is your [roadmap.]"

Without getting into semantics, Moore's Law roughly assumes that things will get cheaper or you'll get significantly greater bang for your buck. "Nobody said it would be easy" is a casual dismissal of the fact that consumers won't pay for this, unless someone conjures a materials revolution.

And no, we can't just assume the head of Intel will conjure up a materials revolution solely to adhere to an industry observational law.

I don't know, man:

https://en.wikipedia.org/wiki/Moore's_law#Moore.27s_second_l...

This talks about an exponential increase in R&D costs which is expected by Moore. With stuff like cloud computing, I don't see the need for denser and denser CPU's going away any time soon.

I've seen electronic microscope image of a working polar transistor in few dozens of atoms. Wires were couple atoms wide. The method employed for that scale was able to place about couple of hundreds of tungsten atoms per second.

It was in 2005. I lost contact with these people, I don't know how they do now.

Intel has a roadmap down to 3nm, and I believe Imec does, as well. But the future is probably a combination of different packaging with faster interconnects and better throughput to and from a variety of memory types. There are a couple of ways to drop the heat. One is a different transistor structure, which may allow for a sharp reduction in voltage (0.1 or 0.2 volts vs. 0.7 to 3.5V). The second way is to use silicon photonics between chips in a package, which is coming one of these days.

> a 5cm processor, if it allowed data to travel at light speed,

Easy. Just have multiple synchronized clock sources.

Strictly speaking, Moore's original paper is not about transitors per chip but about transistors density for the least cost node.

So first it's about transistor density, hence the relation to having smaller and smaller transistor. And also and very important, it's about cost. You could go 3D to increase the amount of transistors per area, but that requires more masks/operations and impact the yield, and increases cost. If in the end the cost per transistor increases, then it's a density increase but it's not advancing Moore law.

In other words, Moore's law can be broken in two different ways: 1) we can't improve anymore the transistor density; 2) we can improve transistor density, but not in a cost effective way. If you want more you need to pay more (vs. getting more for less money when riding Moore's law).

Reply on news.ycombinator.com