Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!oliveb!sun!dgh!dgh
From: dgh@dgh.UUCP
Newsgroups: comp.lang.c
Subject: Optimizing Floating-Point Expression Evaluation
Message-ID: <16646@sun.uucp>
Date: Mon, 13-Apr-87 23:53:08 EST
Article-I.D.: sun.16646
Posted: Mon Apr 13 23:53:08 1987
Date-Received: Wed, 15-Apr-87 04:49:47 EST
Sender: news@sun.uucp
Lines: 71
Keywords: float point expression

SUMMARY: Some recent postings have been missing the point again.
There's an optimal way to evaluate floating-point
expressions, which is to respect parentheses.  Details follow,
but first...

	I am NOT talking about integer expression evaluation.
In C, I can readily believe that there is a significant body of
code that was written with the expectation that constants would
be combined despite parentheses.  I don't think it was wise to
code that way, but there the issue is integer overflow, which many
people understand, rather than floating-point rounding errors,
which sooner or later confuse everyone who encounters them.

	I am NOT posting to complain about the ANSI C committee,
whose members deserve credit for recognizing that the problem was 
serious enough to warrant fixing.  Like many others, 
I think using unary + to signify "I mean this" is pretty odd, 
but it's better than ignoring the problem.  Thus what follows is addressed
more to the implementors of existing C compilers, who will all
have a good way to go to meet the ANSI standard anyway if it's
approved in its present form.

	I AM interested in exposing the real costs of ignoring 
parentheses and the real benefits of respecting them.  
The purported benefit of ignoring parentheses in statements like

	w = (x + y) + z

is that sometimes faster code can be generated.  Possibly in some
cases for some architectures, but interestingly enough
this claim was actually investigated right at the time
C and Unix were being invented.

	Morven Gentleman, who was at Bell Labs in the early 1970's,
heard about this alleged optimization and investigated it empirically,
collecting statistics on programs actually being run there, to find out 
how much was saved.  As might be expected, the answer was no significant amount
of execution time and slight saving in stack space.   He related to me 
that he presented the evidence to Steve Johnson but that the latter had
already made up his mind otherwise.  So much for the benefits.

	What of the costs?  In carefully-written code I would think that
if the order of the additions did not matter, you would just write

	w = x + y + z

and leave it up to fate.  If you write something else you mean
something else.  Lacking a feature equivalent to ANSI-style unary +, 
to get the intended effect it's necessary to write

	t = x + y
	w = t + z

If you had just run out of floating-point registers, this may mean 
wasted extra cycles to write and read storage.  You may even have
to allocate stack space for the temporary that otherwise wouldn't have
been needed.  Now which is more efficient?

	I think this and other aspects of optimization are encapsulated
in the following proposition:  optimizing compilers should be designed to
improve carefully-written code by means that can not be readily expressed
in the source language.  I would have thought that most experienced C
programmers would agree with that proposition, but some recent postings
suggest otherwise: that a major purpose of optimizing compilers is to clean
up after careless coders and thereby encourage careless coding.
	  

David Hough

ARPA: dhough@sun.com
UUCP: {ucbvax,decvax,allegra,decwrl,cbosgd,ihnp4,seismo}!sun!dhough