-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of
Thorsten Siebenborn
Sent: Friday, July 13, 2007 4:20 PM
To: stds-754@xxxxxxxxxxxxxxxxx
Subject: Re: Clause 10, Expression Evaluation
David James schrieb:
Guys,
A few points:
1) I would greatly appreciate a summary of your position,
before delving into details. Would help to understand.
Easy:
David Hough wanted that a language define an evaluation order
to enable reproducibility. E.g.
C = A*A*B A = 1e200; B = 0.0
Is it evaluated from left to right or from right to left ?
If it is from left to right, we have the results 1e200, Inf,
0.0. The overflow flag is set.
If it is from right to left, we have the results 0.0,0.0,0.0.
No overflow.
That is the problem; if the language does not define the exact
order, the result is indetermistic. So David suggested that
language and/or compiler writer define exactly how an expression
is evaluated.
Malcolm Cohen don't...like it. Fortran don't define an evaluation
order. Why ? Because the Fortran compiler writers are obsessed
with speed; expressions may be evaluated in any order,
shortened, culled, short-circuited, whatever...if you get
some more speed, do it. So he not only stated that languages
who have a defined order are inevitably running slow as
snails(V*LV*S), but he declared that the whole idea is bogus.
My position is that he is partly right: it is indeed possible
to get performance gains by optimizing expressions. Moreover, the
growing complexity of processors and their peculiarities (caching,
pipelining,memory access etc.) enforces a peculiar style if you want
maximum performance. So I agree to his point that changing
expression order may be beneficial.
But in my opinion he got too far. The idea is not bogus, it enables
some very valuable debugging techniques not available to Fortran.
Even the speed advantage is debatable; OCaml in single processor
systems and Sisal in supercomputers have comparable performance.
Why ? The compilers are getting smarter and smarter and some programming
techniques like functional programming allow new approaches.
2) The analogy is over-stretched. Please use normal English.
Hope to done it.
3) Mentioning products (even unrelated automobiles) is
inappropriate in IEEE discussions.
What products exactly ? Are supercomputers like ****-*** or *** **-*
allowed ? Or languages like ******,***** or ***** ?
Best,
Thorsten