🚀 go-pugleaf

In article <1109@mindlink.UUCP> a464@mindlink.UUCP (Bruce Dawson) writes:
>     Be careful where you give the credit for the speedup.  Changing the
>algorithm, in this particular case, saved nineteen seconds. [...]

Hmm. Sounds logical; looks like you caught me committing sloppy thinking.
Right, it's additive in this case, not multiplicative.

In any case it's still a good testimonial to those who think that
coding everything in assembler is the only way to go. There was an
article called "FastPix" in the Nov. Amazing Computing that showed
how to do a custom pixel writing routine in assembler to save time,
which will mislead many people.

The impression given is that such a routine would be the ultimate in speed,
just because it's written in assembler. Whereas usually a bigger gain
can be gotten from staying in C and experimenting with different
algorithmic speedups. Using assembler makes sense only when all other
alternatives have been exhausted, and that's the only source of speedup
left.

Several times I've seen commercial products advertised as "(re)written
100% in assembler!!!!!!", as if that were a plus. Inner loops should
be in assembler, not entire programs.
	Doug

P.S. I suppose I'll now be inundated with flames from people pointing
out that, since they have no hard disk, size of programs is critical
to squeeze as many as possible onto their floppies. Yeah, I know, I was
without a hard disk on my Amiga for years. But although some people write
really perfect programs in assembler, with most you pay for that size
bonus with generally buggier programs, simplistic algorithms, etc.
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary