Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!apple!stadler
From: stadler@Apple.COM (Andy Stadler)
Newsgroups: comp.sys.apple2
Subject: Re: languages (compilers and assemblers)
Message-ID: <39854@apple.Apple.COM>
Date: 27 Mar 90 04:03:34 GMT
Organization: Apple Computer Inc, Cupertino, CA
Lines: 93
References:<12435@smoke.BRL.MIL> <3880@sage.cc.purdue.edu>

In article <3880@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu
 (Eric Mulholland) writes:
>
>>Article <7509@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes:
>>>  It seems to me that most programmers ought to be write better code than a
>>>compiler; ...
>
>Article <12435@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) replies:
>>involved, compiled code can run anywhere from somewhat faster (yes!) to
>>several times slower.
>
>    Compilers translate statements into machine code while assembliers
>practicly directly convert to machine code.  The only way compiled code
>can run faster is a sloppy programmer.  A compiler is able to clean up
>some of the mess and thus make faster code, but with a good programmer,
>the compiler would have to be enormesly complex (and slow) to compete.
>

Someone said in an earlier posting that "compilers look at the entire program
and optimize it".  You're all missing the main reason to use compilers:

  A compiled program is easier for the PROGRAMMER to look at and understand.

Everyone keeps talking about cycle-by-cycle style optimizations.  But that's
only half the game.  It is equally important to optimize your algorithms,
data structures, and program execution.

Suppose I have a program, and I determine that it's spending 50% of it's time
in a single routine.  Now, I spend some time, rewrite in assembly, tighten up
the loop, whatever.  Even if I double the speed of the routine, the program
is only 33% faster.  However, if I can redesign my program to not ever use
that routine, I've DOUBLED (100% faster) the speed of the program.

No matter how well structured, an assembly program is longer (to the
programmer - more lines of code) and thus harder to read and "internalize".
You are forced to look at more details, and therefore less high-level
structure.  Let's face it, we're not perfect, we have limited attention
spans, and we need all the help we can get.

>>However, keep in mind that time spent in making non-bottleneck sections
>>of code run faster is time wasted.  Even if you're after speed, assembler
>>should be used for only a small fraction of an application.
>
>    Just because code is written in assembly doesn't mean long hours are
>spent in optimizing every routine.  As mentioned before, macro libraries
>come into play here.  Like with high level languages, they contain common
>routines programmers use.
>

I agree, but only to a point.  Macro libraries or no, I can write code MUCH
faster in Pascal than I can in assembly.  And the less time it takes me to
write the program, the more time I have to debug, measure, and THEN optimize.

This last point is important.  Non-bottleneck sections should be written for
programmer convenience, ease of modification, reliability, etc.  Bottleneck
sections should be written for speed.  However, it is very hard to predict
just where your program will spend lots of time.  The ideal development cycle
is:
  (1)  Write your program.  Get it running as soon as possible.  Investigate
       the features.  Change the design.  Rework it some more.
  (2)  When you are satisfied with the design and implementation, now, and
       only now, MEASURE.  Discover by test, not by prediction, where the
       bottlenecks are.  I promise you'll see both expected behaviors, and
       at least a few surprises.
  (3)  Finally, optimize.  Get in to those bottlenecks, and either rework
       the program to eliminate them, or do the bare-hardware thing and
       crunch them into the world's tightest assembly language.

#1, and the first part of #3 are the domain of high-level languages.  The
compiler can be your friend - let it work for you.  The second half of #3
is where assemblers and excellent knowledge of your CPU (quick!  how many
cycles for an indirect indexed 24 bit addressing load when DP isn't page
aligned?)  are your main strengths.

>    Something else about assembly that I feel important hasn't been
>mentioned.  Assembly code is more compacted!  The shorter the program,
>the more evident this becomes.  See if a compiler can create the "hello
>world" program in about two dozen bytes!  Not two dozen Ks, but bytes.
>One of the reasons for this comes from numbers that only need one byte
>often use two or four!

Please understand that when you compile a program, you don't just get the
compiler output, you also get a whole bunch of library code to go with it.
Problem is, the library code is large and generalized.  It probably contains
enough code to open, read and write disk files, or the console, or whatever.
Some linkers are better than others at discarding unused code;  and some
libraries are constructed better than others.  Try this experiment:  Rewrite
"hello, world" as a desktop program - use NO language-io calls (WriteLN, etc
for you Pascal folks, or printf's for you C types) and NO language-memory
calls (New, Dispose, malloc() ).  If all the work is done by the compiled
program, and the libraries aren't linked in, you'll find much less disparity.

--andy    stadler@apple.com