[MUD-Dev] Re: processors
marc at ias.jb.com
Mon Feb 1 00:08:01 New Zealand Daylight Time 1999
J C Lawrence wrote:
On Sat, 30 Jan 1999 19:00:11 -0800 (PST) diablo <diablo at best.com> wrote:
> J C Lawrence wrote:
> > Could someone like yourself, or someone similarly erudite about such
> > matters speed things up by recoding? Probably, but there's a lot of
> > code, and probably a _lot_ that needs doing. We'll certainly try to
> > do it, but we will also be buying the fastest processor we can
> > afford. I know it goes against the programmers ethic to dismiss a
> > problem by saying "buy more memory" or "buy a new processor" but
> > I've committed worse sins I suppose (though my new coder starts
> > foaming at the mouth everytime I suggest it. I'm a little frightened
> > that upgrading instead of optimizing will kill him.)
> There's a balance in there. Given a competent programmer (for
> suitable values of "competent"), and a reasonable choice of algorithm
> and implementation (nothing wonderful required, just "good enough") of
> that algorithm, then yes, faster hardware is almost always the cheaper
> and more rewarding answer. Programmer time is expensive. Hardware is
> cheap. The counter side of course is that lazy, or pseudo-competent
> programmers come to rely on this, get sloppy with algorithm and
> implementation choices, and then try and answer everything with faster
> If the story is correct (passed on by a mate at SGI), in an earlier
> version of IRIX they killed some "unecessary" buffer copies in the
> TCP/IP stack (as I understand it, just a single extra copy per
> packet). Stack performance gained by over 35%.
> Tiny change. Huge reaction.
I wanted to mention another thing to keep in mind that was not
mentioned. While more memory and more processor and faster disk access is
good, it can, in general only speed things up linearly, while choosing
better algorithms can speed things up sometimes _much_ better than
I always kringe when I read 'Yeah I just used bubble sort because
there will never be more than X and it works great for that'. I read
this with sorting alpha polygons in a 3d engine. What happens when (since
3d hardware is moving so fast) they take their engine, crank up the polys
for a RivaTNT or a VooDoo3 and their performance drops to nothing? Now
they have to dig around old code looking for performance bottlenecks,
checking drivers etc.
Back to writing a NURBS evaluator.
 I am sure there are pathelogical cases where this does not hold.
 Fast 3d card.
 Where x is in the set of positive integers (Z) and is less than 100.
Quicksort is easy to write :-) (and the partition does not have to be the
More information about the MUD-Dev