(j3.2006) (SC22WG5.4773) [ukfortran] [Letter ballot 3 on Fortran 2008interpretations]

[Malcolm Cohen]

>The "performance" argument is entirely bogus, and I will continue to
>believe so until somebody shows me profiler results from a
>representative set of real applications, not artfully contrived SPEC
>benchmarks.

As has been pointed out to you before, SPEC benchmarks are not "artfully 
contrived" but are actually real user programs.

>The desire was to be able to get a default-real
>value, that is, a member of the set of valid values for default real,
>from a double precision argument.  Being able to do this is essential to
>Kahan summation, and other methods to do arithmetic without avoidable
>loss of precision.

Just calculate the sum in double precision then, that's even better.

>This had been done for decades until some vendors intepreted
>"processor-dependent approximation" as NOP, to make some arcane SPEC
>benchmarks run faster.

This is just spurious name-calling.

I dispute your recollection of days gone by (today is not, in fact, harder than 
in bygone days - in fact it is much easier), and dispute the assertion that the 
schemes we used to use before now fail.  We never used the REAL intrinsic to do 
this, because it never did this.

If I am not mistaken, the "arcane SPEC benchmark" slur comes from my pointing 
out that inter-line optimisation is alive and well, and widely used to get good 
performance from the SPEC benchmarks ... and that should be read as "from a 
number of important user programs".  The issue is not new - when F90/00001 
passed (allegedly outlawing inter-line optimisation) there was a mutter from 
vendors around the room to the effect that they were going to *CONTINUE* to do 
this because their users wanted great performance.  Note *CONTINUE*.  This was 
20 years ago!  It was not a new thing then and is not a new thing now.

>Fine.  Add a compiler switch that causes that
>behavior, with a caveat that it causes the processor not to conform to
>the standard.

It is already there, it's called "-O".  If you don't want heavy optimisation, 
turn it down.

Bill wrote:
>However, this argument of
>"better answers", particularly in "the vast majority of cases", does not
>make sense to me.

I am not arguing that the standard needs to change to permit better answers, 
just that it should not change to forbid them.  The naive application of the 
thinking behind this interp would prohibit raising the precision of any 
operation - and this would indeed lead to Worse Answers in the vast majority of 
cases.  In general, evaluating a whole expression in the maximum precision 
available and only rounding it to a smaller storage format on assignment 
produces more accurate results than rounding to the smaller format after each 
operation; this is a plain fact.

>I realize that there was some blather about 80-bit registers, but that's
>history, and I don't really see it coming back.

History is littered with sayings like "640k is enough for everyone".  Let's not 
think we can predict the future beyond the short term.

Anyway, the exact same issues arise on any machine with floating-point register 
sizes that do not match the entire set of storage formats.  This happens to be 
the vast majority of machines today!

(I will say that quirks in the 80-bit hardware combined with short-cuts in the 
compilers of the time led to the 80-bit stuff not being as good as it could have 
been - in fact quite annoying at times; but even so, it usually gave good 
results especially for the user who just wanted their calculation done and were 
not attempting numerical tricks.  Those attempting numerical tricks had to be 
careful, but not a lot more so than on certain other hardware floating-point 
flavours.)

>  Is the whole goal of
>this interp to provide the flexibility, in the future, for some vendor
>to implement this sort of hardware again?

Fortran has never been a straightjacket for floating-point implementations.  The 
submitter of this interp wants it to be.  We should decline this request to add 
a new feature to the standard via the interp process.

FWIW I agree that there is a small but important minority of users for whom 
greater control over precisely what operations are performed would be useful. 
In fact some might notice that I represent a large community of them!  Those 
users are today catered for by a plethora of methods which although are not 
guaranteed to work, do in fact work.  It would be nice to support those users 
better in the standard.  Changing the meaning of the "conversion" intrinsics 
would not be my preferred way, but I would not necessarily be opposed to doing 
in a revision (with added compatibility note in clause 1).  IMO we should take a 
step back and craft such extensions properly, and I think that changing the 
conversion intrinsics is unlikely to be the best possible method.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.