Path: utzoo!attcan!uunet!bu.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Compiler Costs Summary: A simple counterexample Message-ID: <2324@l.cc.purdue.edu> Date: 8 Jul 90 13:38:31 GMT References: <1797@apctrc.UUCP> <103726@convex.convex.com> Organization: Purdue University Statistics Department Lines: 38 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)