5 ms·

Moore’s law is dying. The transistor and clock speed improvements we saw with regular cycles (33 - 66 - 133 - 266 - 433 - 1Ghz!) hasn’t happened in a while, and

Moore’s law is dying. The transistor and clock speed improvements we saw with regular cycles (33 - 66 - 133 - 266 - 433 - 1Ghz!) hasn’t happened in a while, and throughput improvements have happened by architectural cleverness (some of which you might say contributed to spectre/ meltdown et al). A really really interesting corollary goes like this: - Moore’s law delivers a doubling of compute capacity every 2 yrs - capacity yields efficiency improvements in compute capacity per human being - more efficiency per human yields net productivity gains per human - net productivity gains drive economic growth - therefore Moore’s law or something like it is a critical driver of economic growth This is a bit scary of an implication - and why as an industry we’re highly incented to come up with something to keep feeding the masses. If we don’t - a key driver of worldwide economic growth will die. interesting that the article says they’ll keep delivering on the promise - We have to - but is repaint the picture and say that we’re obligated to do so via more exotic software and hardware architectures, so expect to see more purpose built compute in all arenas

misja 7y ago
Moore's law is not about doubling clock speed, it is about doubling the transistor density. This has continued after clock speed improvements have stopped. Even today it is following Moore's law, although not at Intel: https://medium.com/predict/moores-law-is-alive-and-well-eaa49a450188 https://medium.com/predict/moores-law-is-alive-and-well-eaa4...
thrower123 7y ago
We're going to have to relearn how to wring every bit of performance out of the chips we have. I'm bearish on the current trend of bloatier and bloatier runtime environments; stuffing an entire isolated instance of Chrome in a container to run a Todo-list app shouldn't have ever made sense, but it especially does not in an environment where compute and memory is once again precious. I hope that betting on Rust over JavaScript would be the winning play over the next decade, but I'll probably be wrong.
- randcraw 7y ago
  Certainly many kinds of apps (e.g. web- and GUI- and disk- or DB-based) won't care if Dennard scaling has essentially stopped on a uniprocessor. But in other domains uniprocess speed is still their life's blood, like graphics, AR/VR, data-parallel number crunching, secure computing, and increasingly I suspect, non-deepNN forms of AI (like search). As clock rates fall further behind the venerable curve of CPU clock rate doubling, I too wonder how long the 10x to 30x slowdown obliged by interpreted languages can last. It's lovely to write code a bit faster using REPL. But if that code's slow runtime or likelier troubles with portability or error recovery diminish its utility, then that bargain is Faustian. I see some of that already after talking to a few startups who are in need low level coding abilities. These days there seems to be a deficit of folks with proficiency in fare like the GCC toolchain, that is, at the levels of assembler, binary objects and libraries, linkers, and device-drivers. I wonder, given the proclivity of CS academia for the past 20 years to ground their instructional SW concepts mostly at a higher levels than binary (like reliance on libraries, OOPL objects, and pseudocode), if this canny valley is likely to grow into a real obstruction -- esp. now that we likely can afford it least.
- ncmncm 7y ago
  Your best bet for future support for efficient code is a language that emphasizes support for coding powerful, efficient libraries that can be used anywhere, for any purpose, without compromise. Such libraries earn the extensive testing and optimization that widespread usage both demands and justifies. High-level, efficient libraries enable coding at a high level, avoiding low-level pitfalls. C++ is still all alone in pursuing this course, today. Rust might start off in that direction after it matures more.

misja 7y ago

Moore's law is not about doubling clock speed, it is about doubling the transistor density. This has continued after clock speed improvements have stopped. Even today it is following Moore's law, although not at Intel: https://medium.com/predict/moores-law-is-alive-and-well-eaa49a450188 https://medium.com/predict/moores-law-is-alive-and-well-eaa4...

thrower123 7y ago

We're going to have to relearn how to wring every bit of performance out of the chips we have. I'm bearish on the current trend of bloatier and bloatier runtime environments; stuffing an entire isolated instance of Chrome in a container to run a Todo-list app shouldn't have ever made sense, but it especially does not in an environment where compute and memory is once again precious. I hope that betting on Rust over JavaScript would be the winning play over the next decade, but I'll probably be wrong.

randcraw 7y ago
Certainly many kinds of apps (e.g. web- and GUI- and disk- or DB-based) won't care if Dennard scaling has essentially stopped on a uniprocessor. But in other domains uniprocess speed is still their life's blood, like graphics, AR/VR, data-parallel number crunching, secure computing, and increasingly I suspect, non-deepNN forms of AI (like search). As clock rates fall further behind the venerable curve of CPU clock rate doubling, I too wonder how long the 10x to 30x slowdown obliged by interpreted languages can last. It's lovely to write code a bit faster using REPL. But if that code's slow runtime or likelier troubles with portability or error recovery diminish its utility, then that bargain is Faustian. I see some of that already after talking to a few startups who are in need low level coding abilities. These days there seems to be a deficit of folks with proficiency in fare like the GCC toolchain, that is, at the levels of assembler, binary objects and libraries, linkers, and device-drivers. I wonder, given the proclivity of CS academia for the past 20 years to ground their instructional SW concepts mostly at a higher levels than binary (like reliance on libraries, OOPL objects, and pseudocode), if this canny valley is likely to grow into a real obstruction -- esp. now that we likely can afford it least.
ncmncm 7y ago
Your best bet for future support for efficient code is a language that emphasizes support for coding powerful, efficient libraries that can be used anywhere, for any purpose, without compromise. Such libraries earn the extensive testing and optimization that widespread usage both demands and justifies. High-level, efficient libraries enable coding at a high level, avoiding low-level pitfalls. C++ is still all alone in pursuing this course, today. Rust might start off in that direction after it matures more.