"more designers are finding that everyday applications do not require the latest physical designs, Anderson said."
So it's just supply and demand, and the demand isn't there. Is this because 1) software developers can't imagine actually useful ways to double their CPU consumption every 18 months, or because 2) it's too difficult to code for multiple cores?
I think it's both. Software innovation is heavily web-centric right now, and web applications just don't stress the CPU (on the client side). On the server side, most apps aren't CPU bound, and even if they were, server-side volume can't make up for client-side volume.
I think there's a more fundamental problem: software developers can imagine specific ways to usefully use more power, but more general ways (like prediction, suggestion, automating automation itself) are fundamentally hard and not well understood. These things verge on what used to be called AI, and require a different level of complexity from things like operating systems and web browsers, even though the codebase might be smaller. I think there's a complexity problem that hasn't been solved (though procedural, OO, and functional programming were all supposed to solve this, to one degree or another) in any mainstream programming methodology. It's possible that it's solved in academia, but most academic solutions for things in computer science take many years or even decades to reach mainstream programming, for whatever reason.
I don't think it's necessarily that difficult to code for multiple cores in appropriate languages. The problem is that it requires a rethinking of what programming is and how it's supposed to work.
It's difficult to test or examine concurrency interactively. Interactive development and unit testing allow you to answer the question, "does it get the job done, and well?" Before multicore, answering that question was enough. With multicore, the question is, "does it get the job done well, with efficient use of low-level resources, and regardless of the unpredictable interleaving of concurrent instructions?"
This is where functional programming comes in, because it makes the leap from answering the first question to the second trivial.
I saw this talk in person; the argument he made was that many kinds of chips (basically everything except high-end processors, DRAM, and NAND) don't want to move to 22nm fabs because they're so expensive. And since the demand for cutting-edge fabs is dropping, the price is increasing even more.
We've all noticed when the exponential growth in CPU clock speeds turned into a sigmoid, it's been a while already.
I'm not sure I'd as pessimistic as the article is on transistor numbers. I think those will keep doubling on CPUs. The WinTel duopoly will find a way to twist your arm to keep buying CPUs with ever more cores. It's just that most other applications will not get much use from it.
Then again, video editing is becoming more and more popular, so I think a lot of 3rd party application can make good use of parallelism.
Servers of various kinds will be able to use the power. if nothing else, hosting companies will be able to offer cheaper and cheaper "virtual servers" with the same capability.
So long as there is some application for ever more powerful multi-cores, this will work to get more powerful multi-core chips in the hands of consumers.
"predicted in 1965 that the number of transistors on a microprocessor would double approximately every two years"
Right - the microprocessor wouldn't even be invented for several more years. Moore's law is about the number of processors on a chip - and I don't see any real reason they'll stop increasing in the near future. If nothing else, more support functions will move onto the chip or more computing power into smaller chips both of which will support less expensive and lower power use mobile applications.
9 comments
[ 4.6 ms ] story [ 37.3 ms ] threadSo it's just supply and demand, and the demand isn't there. Is this because 1) software developers can't imagine actually useful ways to double their CPU consumption every 18 months, or because 2) it's too difficult to code for multiple cores?
I think it's both. Software innovation is heavily web-centric right now, and web applications just don't stress the CPU (on the client side). On the server side, most apps aren't CPU bound, and even if they were, server-side volume can't make up for client-side volume.
It's difficult to test or examine concurrency interactively. Interactive development and unit testing allow you to answer the question, "does it get the job done, and well?" Before multicore, answering that question was enough. With multicore, the question is, "does it get the job done well, with efficient use of low-level resources, and regardless of the unpredictable interleaving of concurrent instructions?"
This is where functional programming comes in, because it makes the leap from answering the first question to the second trivial.
I'm not sure I'd as pessimistic as the article is on transistor numbers. I think those will keep doubling on CPUs. The WinTel duopoly will find a way to twist your arm to keep buying CPUs with ever more cores. It's just that most other applications will not get much use from it.
Then again, video editing is becoming more and more popular, so I think a lot of 3rd party application can make good use of parallelism.
So long as there is some application for ever more powerful multi-cores, this will work to get more powerful multi-core chips in the hands of consumers.