🚀 go-pugleaf

In article <1992Dec6.021202.20893@colorado.edu>, bear@tigger.cs.Colorado.EDU (Bear Giles) writes:
> In article <MAYER.92Dec4141701@porky.sono.uucp> mayer@sono.uucp (Ron Mayer) writes:
> >He also wrote a fht with a self-modifying
> >block of code (changed instructions in it's inner loop as needed) for
> >the 8086, which was significantly faster than the similar C code.
> 
> Eek!
> 
> You could probably justify an order-of-magnitude difference in performance
> in many situations, once you consider _programmer_ maintanence costs.

	The 8086 is a chip that DOES offer the potential for an
	order-of-magnitude speedup in critical code.  This also applies
	to the 8088, 80186, and 80286; I haven't kept current to know
	whether it applies to the 80386 and 80486.

	The reason is that queue flushes are quite expensive -- if my
	memory is intact from several years ago, the difference between
	a conditional jump that jumps (which means flushing the queue)
	and one that doesn't jump (no queue flush) is a factor of 11
	in relative timing.

	This plus elimination of somewhat time-costly stack accesses
	in function calls are the two most productive candidates for squeezing
	extra speed out of the 8086 chips, at least up through the 286.
	I spent a fair bit of effort doing exactly that on avionics
	firmware that had trouble meeting its real time requirements.
	However, I'd still be reluctant to use self-modifying code --
	especially in cases such as the avionics firmware, whose code
	executed from ROM!

> If you're using an architectural trick it isn't an algorithm, it's an
> implementation detail.

	I'm inclined to agree in the usual case of running on a
	general purpose processor.  It's less clear if you're using
	a special purpose processor, typically a signal processor,
	whose hardware architecture is tailored to suit a specific
	key algorithm, such as autocorelation.


------------------
Paul Raveling
Raveling@Unify.com