Xref: utzoo comp.arch:16966 comp.lang.misc:5101
Path: utzoo!attcan!uunet!lll-winken!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!e2big.mko.dec.com!ceomax!gillett
From: gillett@ceomax..dec.com (Christopher Gillett)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Compiler Costs
Summary: Too subjective to approximate!
Message-ID: <373@e2big.mko.dec.com>
Date: 6 Jul 90 17:07:11 GMT
References: <1797@apctrc.UUCP>
Sender: usenet@e2big.mko.dec.com
Reply-To: gillett@ceomax.dec.com (Christopher Gillett)
Followup-To: comp.arch
Organization: Digital Equipment Corporation, Semiconductor Engineering Group
Lines: 58
Keywords:

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?
>

This is, among other things, an interesting question, but I certainly
wouldn't characterize it as "simple" :-).  There are a huge number of
factors to consider in making this determination, and many of them
are subjective and/or incalculatable.  Here are some things that you
should consider:

     1.  Nature of the program:  Something that is fairly linear and 
         spends all its time calling system functions is not likely
         to be sped up by conversion to assembler.  Something fairly
         complex that uses lots of control transfers, and is reasonably
         non-obvious (itself a very subjective term) is more likely to
         be improved.  

     2.  How good is good?  The quality of the compiler that you are
         using is significant.  Compilers range from utter trash to
         seemingly clairvoyant in their abilities to generate efficient
         code.  Since there's no really good metric that you can apply
         to an arbitrary compiler to determine its effectiveness, you're
         left making a judgement call about whether or not the compiler
         is a better assembly language programmer than you.

     3.  How talented are you?  The art of assembly language programming
         is rapidly dying out.  Many people are really gifted high level
         programmers who fall apart in the assembly world (absolutely no
         jabs at anybody at all intended here, btw :-) ).  Problems are
         solved much differently in the two different worlds.  If you try
         to do a straight translation from high level to low level, you're
         not doing much better than the compiler (in fact, probably much
         worse).  However, if you are a gifted machine-level hacker, and
         you have really understand the program you want to convert (like,
         did you write it yourself?), then you might gain significantly
         by converting the code. 

These are just the first few things that pop into mind.  My opinion on the
whole matter is that you should consider language issues long before putting
down any code.  The very nature of the program should dictate which language
to use.  Further, it's been my observation that code conversion jobs (whether
from one high level language to another, or from a high level to a low level,
or low to high) are expensive, time consuming, and not very rewarding.

>Thanks,

You're welcome!

>Randy

/Chris
---
Christopher Gillett               gillett@ceomax.dec.com
Digital Equipment Corporation     {decwrl,decpa}!ceomax.dec.com!gillett
Hudson, Taxachusetts              (508) 568-7172