4 ms·

The second law of computer science is much more dangerous: "Any program will degenerate until it is written in a conglomerate of perl and shell script." There

by jlouis 18y ago

The second law of computer science is much more dangerous: "Any program will degenerate until it is written in a conglomerate of perl and shell script." There is a windows-corollary: Substitute perl and shell script for VB. Seriously though, I do think the law is right. It will be harder and harder to push further optimization out of programs. It is much more interesting to look at other problems - and I do think the research went there as well.

neilc 18y ago
If you interpret "compiler optimization" broadly enough, I don't think the argument is right: compare the performance of a typical Javascript implementation from 5 years ago with the performance of the best implementations today. That difference in performance is often the factor that allows previously infeasible programs to be written in Javascript.
- SapphireSun 18y ago
  I think what is really going on is a kind of power law thing. After the initial optimizations over about a decade or so, the additional optimizations only help so much. So yes, it is helpful to do the compiler right, but there are diminishing returns after a certain point.
  - nostrademons 18y ago
    Dan Sugalski wrote a post on the Parrot blog a couple years ago that I thought was pretty thought-provoking. In a nutshell, it was: "I think we - compiler and VM writers - have definitely been on the wrong track all these years. Instead of looking for ways to squeeze that last instruction out of a function, we should be looking at memoization, lazy evaluation, and other ways to avoid whole chunks of work." That squares with my experience (as an application programmer, not as a compiler writer). When I've been able to get huge, 2-10x speedups in my programs, it's always been through doing less work, not doing the work more quickly. At my first job, there was an issue with the communication protocol between the UI and a proprietary database. The engineering department spent a month redoing the protocol with batch calls that fetched data with one command instead of individually retrieving each object. They ended up with about a 5% speedup. Then I looked at the logs and saw that a certain very-common API call was actually making two requests to the database, and the data from the second one was not needed in 99% of cases (it was a holdover from when the product was intended for a totally different market). So I changed the API to lazily fetch the extra data only when it was accessed, and within an hour we had a 2x speedup. So yeah, existing optimizations have probably reached a point of diminishing returns. But that doesn't mean that new approaches might not result in big speedups.

by jlouis 18y ago

neilc 18y ago

If you interpret "compiler optimization" broadly enough, I don't think the argument is right: compare the performance of a typical Javascript implementation from 5 years ago with the performance of the best implementations today. That difference in performance is often the factor that allows previously infeasible programs to be written in Javascript.

SapphireSun 18y ago
I think what is really going on is a kind of power law thing. After the initial optimizations over about a decade or so, the additional optimizations only help so much. So yes, it is helpful to do the compiler right, but there are diminishing returns after a certain point.
- nostrademons 18y ago
  Dan Sugalski wrote a post on the Parrot blog a couple years ago that I thought was pretty thought-provoking. In a nutshell, it was: "I think we - compiler and VM writers - have definitely been on the wrong track all these years. Instead of looking for ways to squeeze that last instruction out of a function, we should be looking at memoization, lazy evaluation, and other ways to avoid whole chunks of work." That squares with my experience (as an application programmer, not as a compiler writer). When I've been able to get huge, 2-10x speedups in my programs, it's always been through doing less work, not doing the work more quickly. At my first job, there was an issue with the communication protocol between the UI and a proprietary database. The engineering department spent a month redoing the protocol with batch calls that fetched data with one command instead of individually retrieving each object. They ended up with about a 5% speedup. Then I looked at the logs and saw that a certain very-common API call was actually making two requests to the database, and the data from the second one was not needed in 99% of cases (it was a holdover from when the product was intended for a totally different market). So I changed the API to lazily fetch the extra data only when it was accessed, and within an hour we had a 2x speedup. So yeah, existing optimizations have probably reached a point of diminishing returns. But that doesn't mean that new approaches might not result in big speedups.