Re: [dev] Interesting post about X11

On Tue, Jun 22, 2010 at 2:45 PM, Thorben Krueger
<thkruege_AT_googlemail.com> wrote:
> On 22 June 2010 20:17, Kurt H Maier <karmaflux_AT_gmail.com> wrote:
>> On Tue, Jun 22, 2010 at 1:55 PM, Donald Allen <donaldcallen_AT_gmail.com> wrote:
>>> So, if we take you at your
>>> word, you are advocating returning to writing assembly code. As
>>> someone who wrote his first computer program in 1960 in assembly
>>> language on an IBM 1620, and who wrote an awful lot of assembly code
>>> in the 1960s and 1970s, I can assure you that's not a good idea.
>>
>> And if we take you at your word, are you advocating that we follow
>> abstraction out until we're using touchscreens to drag Sprog[1]
>> widgets around?  I sure hope not.
>>
>> I think what should be pursued is a balance between abstracting out
>> pain-in-the-ass boilerplate (of which modern C is full) and reducing
>> programming to mindless library-gluing (which is what Java gave the
>> world). To be perfectly honest, no matter how well your Scheme program
>> runs, if it takes up much more system resources than existing C
>> programs, I don't want it.  It's not just about easing the development
>> load by throwing hardware at the problem -- we've had enough of that.
>
> A word of caution from Don Knuth at this point: "Premature
> optimization is the root of all evil."
>
> I have grown to cherish this piece of wisdom over the years, as it
> often turned out that I had focused my energies on the wrong problems.
> I am not saying that implementing something in C is "premature
> optimization", but choosing C over a higher-level language for
> performance reasons should not be something you do unquestioningly or
> "as a rule".

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.

>
> If you have a simple program which mostly does I/O, _that_ is going to
> be your bottleneck. Don't worry about the number of instructions your
> CPU has to execute.

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.

Programmers are notorious for not understanding the performance
characteristics of their own code. Permit me a war story (that's what
old guys do). The first host-level implementation of tcp/ip was done
by a guy who worked for me at BBN (I'm referring to the second
implementation of any kind. The *very* first implementation was done
by Ray Tomlinson at BBN on a PDP-11 that was a remote printer server;
Ray is the person who sent the first email across a network and who
invented the '@' notation.). This code was written in PDP-10 assembly
language. it was very well-written, but unacceptably slow. The guy who
wrote it said "I know what's wrong; I'll fix it" and he did some
re-writing/re-structuring of the code. It didn't work. We went through
one or two more unsuccessful iterations of this before I insisted that
he make measurements of where the time was going (this was not easy to
do in this environment -- we didn't have anything like the tools that
exist today for debugging and performance analysis). Turned out that
the connection hash table was too small and the code was spending a
lot time doing linear searches. A single constant got changed to
increase the hash table size and the problem went away.

>
>> There's no reason I need to bog down my computers with langauge
>> interpreters -- much less crimes against nature like emacs.  There are
>> plenty of regular languages out there that don't need the
>> infrastructure scheme does, many of which have already been mentioned
>> in this thread.

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.

/Don

>>
>> Thanks for the book link, though -- I didn't know that was available
>> online these days!
>>
>>
>> --
>> # Kurt H Maier
>>
>>
>
>
Received on Tue Jun 22 2010 - 19:16:11 UTC