Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!uxc!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!phil
From: phil@ux1.cso.uiuc.edu
Newsgroups: comp.sys.ibm.pc
Subject: Re: High- vs. low-level languages (Was:
Message-ID: <17100001@ux1.cso.uiuc.edu>
Date: 15 May 89 21:35:00 GMT
References: <664@tukki.jyu.fi>
Lines: 55
Nf-ID: #R:tukki.jyu.fi:664:ux1.cso.uiuc.edu:17100001:000:3033
Nf-From: ux1.cso.uiuc.edu!phil    May 15 16:35:00 1989


> portable C compilers!), not efficiency.  FORTRAN is one of a very
> few languages with truly excellent optimizing compilers.  
> 
> A good optimizing compiler can beat assembly programming, and it
> has been shown in several challenges between programmers -- one
> of which was written up several years back regarding a challenge
> sponsored by some folks at IBM.  Numerous experienced FORTRAN and
> assembly programmers were given the same problem to solve.  The
> FORTRAN programmers beat the assembly programmers every time in
> terms of execution speed.  However, given the code generated by
> the FORTRAN compiler, the assembly programmers were able to
> improve upon the code by about 10%.  

This sounds like a case of bad assembler programmers.  There are lots of
them around.  In fact MOST programmers are probably bad assembler programmers.
If the programmer wrote slower code the first time then improved it upon
seeing the compiler code, then there must be something wrong.

Actually I was in a similar situation when writing a Mandelbrot program on
an IBM 370 mainframe.  I compiled the program with the maximum optimization,
yet found absolutely pathetic code generated for the main iterative loop.
I recoded in assembler and got several times speedup.  I did all the
calculations in registers, whereas the compiler had at least two cases of
storing a number and loading it back again INTO THE SAME REGISTER and it
didn't even need the number again.  The optimization could have been a whole
lot better.  I have heard that VAX/VMS Fortran is well optimized but have no
way to verify that myself.

I do agree with the idea of writing the main structure of a program in a
high level language, and putting the heavy duty computation parts, or the
sneaky system access parts, in assembler.  I also consider it important to
highly document the interface between these parts so that if the program is
ported to another machine type, there is a reasonable chance to implement
the assembler parts on the other machine as well.

> The examination of the differences indicated that the high-level
> programmers' were able to concentrate more on algorithmic
> efficiencies at every implementation level and were not as
> distracted by implementation details as the assembly language
> programmers.  Many assembly programmers challenge this and invoke
> incantations of initial PDL designs, macro-packages, and
> subroutine re-use which simply goes to make my point (they are
> simply lifting themselves up toward high-level language
> programming by doing so).  The best programmers use all the tools
> they have to do the best job, including assembly language
> reprogramming of critical sections of code if other factors
> permit.

That depends on how much assembler program one has done.  On the PC this
will be the case for me for a while still.  On the IBM 370 mainframe, the
implementation details are trivial for me, as I have written well over 2000
programs or general purpose subroutines entirely in assembler.

--phil