On Tue, Jun 22, 2010 at 3:16 PM, Donald Allen <donaldcal...@gmail.com> wrote: > Absolutely. Furthermore, there is far more leverage at the algorithmic > level in a lot of cpu-intensive problems than there is from code > optimization. In other words, if you've written something in Scheme > that's too slow and the problem is that it's O(n^2) or worse, attend > to the algorithm before you consider reimplementing in C.
That doesn't help me with the dbus process sitting on 5% of my CPU resource and a hundred megs of ram. It's all very well to talk about how stupid most programmers are -- nobody here is going to argue that -- but most software in common use on unix/linux systems is of the "work harder, not smarter" variety. > Again, absolutely correct. I can't tell you how many times I've > observed people doing micro-optimization of the code to save a few > cycles -- in I/O-limited programs. It's surprising how many people > don't understand some basic results of queuing theory, one being that > if you aren't making your bottleneck resource faster or reducing the > demand for it, you aren't making your system or program faster. Which again isn't entirely relevant for systems programming. Computers do tons of stuff without needing to wait for user interaction, especially in, say, biology labs. I've seen *idling* database applications drop from 700mb ram usage and moderate CPU load to 200mb ram usage and near-zero CPU load just by upgrading the version of python interpreting the code. Any time I can cut out a layer of stuff, I'd prefer to do it. At least then there's only one place to look for bugs. > To Kurt Maier: So you prefer to make things easier for your 3 Ghz/4 Gb > computer at the expense of making things more difficult for yourself? > Not sensible cost-benefit analysis, in my opinion. No, I'd prefer to make things easier for my 1.2GHz/768MB computer without making anything more difficult for myself. That's a large part of the point of "suckless" software. In fact, if I can lighten the computer's load without hurting my workflow, I come out ahead -- because now I don't have to go buy a 3GHz/4GB machine to support the skyward-rocketing tower of bytecode interpreters that the IT industry seems to love building. -- # Kurt H Maier