Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Re- HLLs vs. Assembly
Message-ID: <1991Apr10.203703.21010@nntp-server.caltech.edu>
Date: 10 Apr 91 20:37:03 GMT
References: <9104060651.AA18946@apple.com> <1991Apr6.100927.21953@nntp-server.caltech.edu> <1991Apr9.150402.563@latcs2.lat.oz.au> <15782@smoke.brl.mil> <6965@rex.cs.tulane.edu>
Organization: California Institute of Technology, Pasadena
Lines: 61

lang@rex.cs.tulane.edu (Raymond Lang) writes:

>I always thought one of the reasons for using a HLL was so you could
>program without having to know the grungy details about the hardware.

Yes, but modifying the program to improve performance requires

	(a) better overall algorithms &/or data structures
	(b) knowledge about the hardware and what the compiler will produce

For instance, one of the unix machines I get to work on is a Convex XP-1,
it's screamingly fast BUT there is a ferocious amount of overhead per I/O
transfer. A program that fread's 32K chunks will scream past a program that
uses fgetc() for any reasonable application that I know of. It also has a
vector processor, but the vectorizer can't optimize code like

double p[dim], dp[dim];	int i, j;
for (j=0; j<255; ++j)
	{
	for (i=0; i<dim; ++i)
		p[i] += dp[i];
	action(p);
	}

You'd think it could optimize the inner loop too, but it can't because dim is
a variable and not a constant. On the other hand,

double p[MAXDIM], dp[MAXDIM]; int i, j;
for (j=0; j<255; ++j)
	{
	for (i=0; i<MAXDIM; ++i)
		p[i] += dp[i];
	action(p);
	}

should allow vectorization of the inner loop. what would be even faster (I'll
be trying this sometime over the next week, for a grade, so if anybody's
interested in the results I'll post them) is to write a vectorizable version
of the outer loop as well -- this requires knowledge of action() which in
my case is a simple quantization routine (it's a polygon tiler that performs
linear interpolation across scan lines).

The point of all this is that while HLL's insulate you from the grunge, they
often make it hard to obtain optimal performance. The set of fully portable
modifications that yield pure improvement on any machine is very small
compared to the set of modifications you can make when you have some
knowledge of the machine hardware and how the compiler will react to the
program (including the various optimizer switches you can invoke).

Writing portable code that compiles well on your machine is generally the
best way to go; only when performance or coding time is more important than
portability should assembly be used -- and it too can be made portable with
#ifdef's. This is in fact how I have the same graphics system compiled and
running on a GS (with a single low-level driver file) as well as on the Convex
XP-1 (also with a single low-level driver file). There is some GS-specific
assembly and type casting (Orca's math library is somewhat nonstandard) but
that is #ifdef'd to equivalent ANSI C code or dummy functions when compiled
under anything but __ORCAC__.

Todd Whitesel
toddpw @ tybalt.caltech.edu