Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!mcvax!kth!draken!tut!santra!tukki!makela
From: makela@tukki.jyu.fi (Otto J. Makela)
Newsgroups: comp.sys.ibm.pc
Subject: High- vs. low-level languages (Was: Re: Why unix doesn't catch on)
Summary: Speed is not the only criteria... effort counts also !
Message-ID: <664@tukki.jyu.fi>
Date: 30 Apr 89 01:16:51 GMT
References: <274@tree.UUCP> <635@eecea.eece.ksu.edu> <2333@rpi.edu>
Reply-To: makela@tukki.jyu.fi (Otto J. Makela)
Followup-To: comp.lang.misc
Organization: Grand Hall of Justice, Mega-City One
Lines: 56

In article <2333@rpi.edu>, fargo@pawl.rpi.edu (Irwin M. Fargo) says:
|[...]  C programs are NEVER going to run faster than Assembler
|programs on the SAME machine.  I am all for portability, but fast portability.
|In my opinion, as software techniques become more and more refined, we will
|be able to create more powerful optimizing compilers for less money.  I can
|envision a day (a day quite some time away) when a compiler will be able to
|create compiled code that runs only marginally slower than the same Assembler
|program.  If anything, I feel THAT is something we should shoot for.  If we
|can reach that goal, then the trade-off between portability and speed will
|become almost unnecessary.
|
|Thank you and happy hunting!             Actually: Ethan M. Young
|  ____ [| SB <]    "Travel IS life"      Internet: fargo@pawl.rpi.edu
| /__   -=|??<=-       - Irwin M. Fargo   Bitnet (??): usergac0@rpitsmts.bitnet
|/   ARGO : 3000 years of regression from the year 4990

Just a comment on the claim that C programs are never going to run faster
than the same programs written in assembler...

This is true, in principle.  However, the clou is the phrase "same program".
Most of the time the assembler programmer does things in a more straightforward
way, making for simpler algorithms (I know, I'm one...).  Things like DOS's
lack of buffering etc. can cause severe problems.

Examples from DOS:
* SORT is veeery slow.  A C-written program which uses the C library's built-
  in buffering can easily be 2-3 times faster than the original
* actually, anything that reads from stdin and writes to stdout (which are
  then redirected) can be made a lot faster with added buffering
* the speed of reading from a file to a buffer can differ drastically
  depending if the file position and the buffer have the same parity, ie.
  if the file position and buffer are both even/odd or if they are not

The point I'm trying to make here is that portability is not the only reason
to program in a high-level language.  The ready-made libraries, the more
complex control and data structures make life easier for the programmer.

It is of course possible to make very fast programs in assembler, but it does
require lots of effort and special expertise (for example, are you aware that
optimizing multiply operations to shifts can be SLOWER on 8088-based machines
since the 8088 is so bus-bound ?).  The motto is: "No Pain, No Gain."

Most of the programs I write are written in C, with speed critical and
system dependent parts done in assembler.  The C package I use includes a
very good interface macro package for calling assembler from C and vice
versa.  This would seem to be the ideal solution while waiting for the
optimal C compiler...

Sorry for the long-windedness. As this has nothing to do with ibm.pc,
I'm directing the followups to comp.lang.misc -- too bad there is no
talk.programming :-) ...
Otto J. Makela (with poetic license to kill), University of Jyvaskyla

InterNet: makela@tukki.jyu.fi, BitNet: MAKELA_OTTO_@FINJYU.BITNET
BBS: +358 41 211 562 (V.22bis/V.22/V.21, 24h/d), Phone: +358 41 613 847
Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE