[MUD-Dev] Re: processors

[Marc Hernandez]

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
> hardware.

> 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[1] only speed things up linearly, while choosing
better algorithms can speed things up sometimes _much_ better than
linearly.
	I always kringe when I read 'Yeah I just used bubble sort because
there will never be more than X[3] 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[2] 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.

Marc Hernandez
[1] I am sure there are pathelogical cases where this does not hold.
[2] Fast 3d card.
[3] 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
first item).