Moore's law only worked for hardware, software lagged typically two years behind.
Ah, but some software companies try to "keep up". One way is to write all software to REQUIRE hardware that came out this year^H^H^H^H month^H^H^H^H^H week. For those of us who do not buy all new equipment every month, it means that running on "obsolete" hardware gives us extremely slow and crowded environment. "Tech Support": "I didn't know it would even RUN on anything that old! That's almost six months old!"
So, MY hardware lags too far behind what Microsoft, etc. use and require for their software!
On Fri, 6 Oct 2017, Paul Koning via cctalk wrote:
There's a more cynical view, sometimes called "the virtual disease", which is that software performance is constant because all the gains from Moore's law have been consumed by increased software inefficiency and complexity.
A related aspect is a corollary of Boyle's Law. Although capacity might double every 18 months, the software will expand to fill all available space. "Modern" software is distributed on DVD, because it will no longer fit on a CD (2/3 GB). How much longer before 8GB ceases to be adequate?
Both of these are slightly unfair but much too close to the truth for comfort.
I have long held that while initial creation of software can benefit from providing the programmers with the absolutel latest hardware, that at least one significant stage of debugging and optimization should be done on the old stuff that "the rest of us" use. If Microsoft would trade hardware with us, and use some of our "obsolete" stuff, then they might learn to write RELIABLE compact, efficient, and fast programs. Instead, the approach to all performance complaints is "throw hardware at it". "Tech Support": "You think that our programs are too slow? That is because YOUR hardware [including YOU] is INADEQUATE."
Too much system software is incapable of properly and gracefully handling things that go wrong. Examples include back to SMARTDRV hanging the computer if it encountered a write error! (It already told the OS that the write had been successfully done, and now it can't DO it!). When programmers never use flaky hardware, then they never learn to write code that can handle the flakiness of the real world.
But, it is a common attitutde. I gave an assignment of writing a program that could sort a data set that was too big to fit into memory. Students COMPLAINED (including complaint to the dean), saying that the "CORRECT" solution is replace the computer with one with more RAM. Response to assignment of optimizing an algorithm to make it more efficient was: "replace the computer with a faster one." They refused to accept the premise that there is any benefit to efficient data structures or efficient algorithms.
-- Grumpy Ol' Fred [email protected]
