On Tue, Jun 22, 2010 at 3:33 PM, Kurt H Maier <karmaflux_AT_gmail.com> wrote:
> On Tue, Jun 22, 2010 at 3:16 PM, Donald Allen <donaldcallen_AT_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
>
>
Received on Tue Jun 22 2010 - 21:19:09 UTC
This archive was generated by hypermail 2.2.0 : Tue Jun 22 2010 - 21:24:02 UTC