Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels!xtbjh
From: xtbjh@levels.sait.edu.au
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <15809.278a0d04@levels.sait.edu.au>
Date: 8 Jan 91 18:18:44 GMT
References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <1047@gistdev.gist.com>
Organization: Sth Australian Inst of Technology
Lines: 43

In article <1047@gistdev.gist.com>, flint@gistdev.gist.com (Flint Pellett) writes:

[...]
> 
> If there is someone who says they aren't concerned with efficiency of the
> algorithms, then I'd have to wonder how experienced that person is in the
> real world of business.  I've noted two things:
> 
> 1.  In large multi-user systems, the power of the system often does
> not expand any faster than the demands on it do. [...]
> 
> 2.  You have to compete with the rest of the world. [...] 

I agree strongly that software is an engineering discipline.  Any program 
is a trade off between many competing forces, including correctness, 
reliability, reusability, maintainability as well as speed, memory, disk etc.

Our main product is a fuel management system that sits alongside petrol 
pumps in refuelling bays.  Each time we ship a system, we have to pay for 
the parts and assembly of the hardware, whereas we can copy the software 
essentially for free.  Since the market is very price-sensitive and 
competition is fairly fierce, we choose to trade high-powered hardware for 
more effort on software, which in turn forces attention onto the performance 
of the algorithms.  

The art of producing "good" systems will always turn out to be the art of 
engineering "good" interfaces (hardware, software, user).  Efficiency is 
always an issue in the technology involved in the interface and in the 
engine that is behind the interface.  Many existing interfaces - and in 
particular procedural languages such as Algol, C etc - are quite inefficient 
since they force parallel tasks into a series of sequential operations.  Any 
interface overhead (procedure call, opcode fetch, signal propogation) 
is then magnified many times.

> -- 
> Flint Pellett, Global Information Systems Technology, Inc.
> 1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
> uunet!gistdev!flint or flint@gistdev.gist.com

--
Brenton Hoff (behoffski)		xtbjh@levels.sait.edu.au
Senior Software Engineer
Transponder Australia