From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9c86eb13dd395066
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: CRC in Ada?
Date: 1997/03/11
Message-ID: <dewar.858095506@merv>#1/1
X-Deja-AN: 224745726
References: <1997Mar2.220652@nova.wright.edu> <1997Mar5.131846.1@eisner>
 <5fmo1k$adm@mulga.cs.mu.OZ.AU> <1997Mar6.114441.1@eisner>
 <E6n850.3Ct@world.std.com> <1997Mar7.090814.1@eisner> <33206340.2616@bix.com>
 <1997Mar7.202252.1@eisner> <dewar.857828494@merv>
 <5fub2s$8k@fozzie.sun3.iaf.nl>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-03-11T00:00:00+00:00
List-Id: <comp.lang.ada>


<<<<But what surprises me is that in cases where the argument is *known*
to be larger than 1.0 the checks are still being made. Normally I would
use a subtype Positive_Float for values which should be positive in a
calculation. This will give a good compiler the opportunity to omit the
extra comparisons in the Ada code.

Sadly enough GNAT is not (yet) such a good compiler in this respect.
In fact GNAT should be able to generate faster code for invocations of
the log function for such arguments, since it can inline the function
to *only* contain the log instruction.

There are many real-world examples where optimizations like these
can make a difference of a factor 3 and more, so I guess these
optimizations satisfy Robert Dewars criterea.>>


That's a pretty marginal optimization. Maybe Geert makes subtypes
Positive_Float, but of all the code we ever had submitted to us,
no one ever bothered to do this, they just used Float.

Still it can go on the list, it's way down there in priority though,
there are MANY more important optimizations ahead of it!

Note of course that Geert's optimization is only possible in any
case if the log function is inlined.

(i.e. if you compile with -gnatn or -gnatN)

So I don't think this is so sad! My experience, as I mentioned before
is that people are always worrying about individual optimizations, but
these individual worries often correspond to optimizations that end
up being disappointing. This particular one is likely to be disappointing
because most people will use plain float as the type anyway.

I do agree that it is surprising how much extra time these comparisons
add (that of course is HIGHLY target dependent, so the other thing to
think about in getting enthusiastic about this optimization is to
find out how much it will help on various targets).

Note that anyone really worried about this problem can trivially call
the C log function directly anyway (not unreasonable, since it is a way
of clearly documenting that you don't need the Ada semantics)

Incidentally, the reason that optimizations like this are not so easy
is that gcc does not know about subranges, since C doe not know enough
about subranges. So gcc does not know about optimziat9ions. The optimization
under discussion here is of course one that has no conceivable analog in
C or C++ (I guess the "sadly enough GNAT is not such a good compiler" gets
translated into "sadly C and C++ are not such good languages" :-)

It's always hard to get very worked up over optimizations for numerical
code that could not be done in Fortran or C compilers. 

The first item of business is to get the Ada code to be fully comparable
to Fortran code, which is a tall order already! Then we can worry about
refinements like this which make carefully written Ada code faster
than Fortran!

Note in particular that right now, the most significant optimization issue
for GNAT numerical code has to do with handling of unconstrained arrays,
which, on certain targets, is still non-ooptimal.