4 ms·

"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 dema

"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.

randallsquared 18y ago
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.
banned_man 18y ago
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.
wmf 18y ago
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.

randallsquared 18y ago

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.

banned_man 18y ago

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.

wmf 18y ago

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.