🚀 go-pugleaf

In article <103726@convex.convex.com>, patrick@convex.com (Patrick F. McGehearty) writes:
> In article <1797@apctrc.UUCP> zrra07@backus (Randall R. Appleton) writes:
> >I have a simple question: ...
> >In other words, if I take my average well written program, compiled
> >with a good optimizing compiler, and re-write it in assembler, what sort
> >of speedup should I expect to see?

			.............................

> It is more common than people realize to have assembly code which is
> much slower than the best high level language program as well as
> much harder to maintain and enhance in the future.  Going to assembly
> too early makes it harder to radically revise an algorithm.
> 
> In the best of cases, 0-4% gain might be obtained.
> For many combinations of compilers and assembly code writings 10-20%
> 	is available.
> For the real turkey compilers and really wizard tuners, >100% has been seen.

There are very simple situations where no compiler not being provided with the
assembler code already has a hope of doing a reasonable job in the language.
Since this is a classic example, the 4.2BSD code being in portable C, I will
remind the readers of it, as well as adding a few comments at the end.

The function is frexp(x,&n).  The argument x is a double precision floating
point number.  The result is to be that number scaled down by a power of 
2 so that the absolute value is between .5 and 1, with the power stored in
the location &n.

Now I submit it will take a real turkey machine language user to match the
slowness of any program written in C or Fortran, USING ONLY THE OPERATIONS
OF THOSE LANGUAGES.  Also, inlining, with n being placed in the register
where it is to be used, is likely to cut the running time by more than
half.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)