On Tue, Jun 22, 2010 at 3:33 PM, Kurt H Maier <karmaf...@gmail.com> wrote: > 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.
But dbus is out of your control. If you need it, you need to accept how it behaves. We're talking about code *you* control. > >> 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. Well, I certainly agree with simplifying. I don't think any of us think overly-complexified code is a good idea. > >> 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. I think you've digressed into the realm of well-architected code that is as simple and lean as it can be, when were talking about programming languages originally. I think the suckless philosophy is about the former, not the latter. And I heartily agree with it. I run Slackware and dwm. No Windows, no Mac, no gnome, no kde, no xfce. No Ubuntu. I want what I need and nothing more. I think a desire for simplicity and good architecture is orthogonal to the language you implement a good (or bad) architecture in. /Don > > > -- > # Kurt H Maier > >
