Re: Apex vs GNAT on solaris

[Robert Dewar <robert_dewar@my-deja.com>]

In article <384e52db.779218947@newsnew.draper.com>,
  rracine@myremarq.com (Roger Racine) wrote:
> That is a pretty questionable reason for creating a default.

Not at all. You certainly want the various gcc front ends
to be compatible (lots of people create mixed language
programs). In any case, as people have pointed out here,
having the default be the fast compile option suitable
for development probably *is* the most convenient default
for most people.


>Perhaps
> compiler documentation should state reasons for using the
various
> options.  Of course, a given vendor might not want to say
"turn
> optimization on only as a last resort, since it is not well
tested",
> but certainly ACT (from what you say) should tell their users
to turn
> it on.

Perhaps you should read the documentation :-)

Here is the relevant excerpt

-----------
@item -O3
full optimization, and also attempt automatic inlining of small
subprograms within a unit (@pxref{Inlining of Subprograms}).
@end table

Higher optimization levels perform more global transformations
on the
program and apply more expensive analysis algorithms in order to
generate
faster and more compact code.  The price in compilation time,
and the
resulting improvement in execution time,
both depend on the particular application and the hardware
environment.
You should experiment to find the best level for your
application.

Note: Unlike some other compilation systems, @code{gcc} has
been tested extensively at all optimization levels. There are
some bugs
which appear only with optimization turned on, but there have
also been
bugs which show up only in @emph{unoptimized} code. Selecting a
lower
level of optimization does not improve the reliability of the
code
generator, which in practice is highly reliable at all
optimization
levels.
----------------------------

> I do not know about your experience, but for me, with embedded
system
> compilers (which tend to have comparatively few users compared
to
> workstation compilers), for numerous languages over the years,
it has
> always been dangerous to change the default optimization
options.

Not at all

> ACT
> might want to reconsider their default.

We don't know of any customers who have a problem with the
default now. If we did change the default, then for sure that
would create massive confusion.

> How do you know this?  As an ACT user, I have never been asked
> about my settings (-O2).  And the GCC world is pretty big.
> You certainly have not asked all those users.

Of course we have not asked "all those users", but we definitely
are aware enough of general usage to make me quite confident
in telling you that virtually all users of gcc go to at least
-O1 for production purposes. Sure there could be an exception,
but we work closely with many customers, and we never saw an
exception to this rule.

> This is not a guess, it is my experience with other compilers.
> And, as you have said many times, do not believe everything
> you read on newsgroups.  :-)

Well I am sorry other compilers have taught you to be afraid
to optimize. It is definitely not a good idea to assume that
all compilers are the same in this respect. If you insist on
believing your experience with other completely unrelated
compilers over our documentation that is of course your
decision, but it can lead to suboptimal decisions.

> As I said above, for GNAT I personally do use -O2, but only
because I
> did a bit of checking (such as the optimization level used in
your
> Make files and for the ACVC tests, or whatever they are called
now),
> but there are many others who have similar experiences and
have not
> done any checking.  They will use the default.  By the way,
why don't
> you use -O3?

We generally do not recommend -O3, though it depends on the
particular circumstance, -O3 will of course generally increase
the size of the executable, and icache effects can often cancel
out expected gains.


> This is confused.  My message said nothing about Posix vs FSU.

Actually your message talked about how you can expect the
default options to be more reliable, and then said "the same
can be said for tasking".

If, as seemed clear, you were saying that the default tasking
is more reliable, this is in fact incorrect.

> But you seem to be agreeing with me that it is better to use
> the default for threads.

Not at all. There is no "better to use", it depends on
particular customer needs. I think the majority of customers
will prefer the default, but there are many reasons to choose
the FSU package instead, one of which is higher performance,
the other is higher reliability and faithfulness to the
required Ada semantics (FSU was of course used for validation).

> By the way, unless you have changed something, your
> version of FSU Threads is -not- Posix compliant, as we have
> discussed previously.  ACT is using an old version that was
> based on one of the proposed Posix standards.

That's irrelevant, since the access to the tasking facilities
must be via the Ada tasking anyway. We strongly recommend
against any Ada program directly or indirectly making posix
threads calls other than via the Ada runtime, it almost always
gets people into trouble.

> Nor does it seem to indicate much logic.  "We do it because
> everyone else using the common back end does it."

We consider consistency of software interfaces to be valuable.

> We certainly do not want anyone to use the default."  :-)

Umm, that's a really strange claim. Most people use the default
most of the time, because during development you usually prefer
to use low optimization levels, giving better debugging behavior
and faster compilations. In fact the reason the gcc defaults
are set the way they are is PRECISELY this fact! And indeed
as you have seen in this thread, there are definitely users who
agree. If you use -O2 for all your development, there is nothing
wrong with that, but it is unusual.


> How would the usage be different if you had a different
> (better) default?

We don't see optimization on as a better default!

> For gnu C, users would need to say "gcc -O1 XXX.c" to get
> the first level of optimization.  For Ada, users could say the
> same thing, or they could say "gcc XXX.adb" to get that same
> level (assuming your default were -O1).  Why do you consider
> that to be an overriding reason?

Consistency is important here. Roger I know you are allergic
to C and want to do everything in 100% Ada, but actually the
more usual profile of our users is that they are doing at least
some mixed language programming.

If we really felt the default were wrong, we would consider
changing it, but in fact we agree with gcc's choice of defaults
anyway. There is certainly no disadvantage in practice (we don't
see any problem of users shying away from optimization merely
because it is not the default -- why, even you, who are SO
inclined to use the default, end up following normal practice
and using -O2 :-)

The one disadvantage of the no optimization default seems to
be the problem of naive benchmarking, which in fact is the
scenario that started this thread.

But I don't think it is right to change the default just because
of this concern. Indeed, anyone doing benchmarks who does not
understand the need for carefully studying what options should
be used is going to get meaningless results in any case.


Sent via Deja.com http://www.deja.com/
Before you buy.