Xref: utzoo comp.arch:16965 comp.lang.misc:5100
Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!mailrus!iuvax!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Compiler Costs
Message-ID: <2317@l.cc.purdue.edu>
Date: 6 Jul 90 15:41:15 GMT
References: <1797@apctrc.UUCP>
Followup-To: comp.lang.misc
Organization: Purdue University Statistics Department
Lines: 22

In article <1797@apctrc.UUCP>, zrra07@backus (Randall R. Appleton) writes:
> I have a simple question:  Does anyone know what sort of speed-up
> on gets by going from a good implementation of some algorithm in a
> third generation language (C, Fortran) and a good optimizing compiler
> to hand-coded assembly?
> 
> 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?

This only looks simple.  The results might even be drastically different
on different machines.  Even the choice of algorithm might depend quite
heavily on the specific machine.  The infamous 4.2BSD frexp() was an 
example of a problem which can be efficiently (and even very simply) coded
in assembler, but which cannot be efficiently handled by such limited 
languages as those mentioned.  The thing missing from these languages 
are the operations of pack and unpack; utterly trivial, but not there.
In fact, even less is needed on most machines.
-- 
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)