Re: Do we need "Mission-Critical" software? Was: What to Do?

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

In article <93bv37$43b$1@nnrp1.deja.com>,
  n_brunot@my-deja.com wrote:
> > Nope, it is the ONLY portable way, then and now.
>
> Most people who find interesting new things are the ones who
> don't trust this kind of assertion :-)

Well the assertion happens to be correct in this case (and
no one has shown any specific data to claim otherwise).

> This is very often used explanation ...
> Ada detractors used exactly the same not so long ago ...
> And as far as ftp is concerned, let's not talk again about
> that for gnat ...
> there is enough in threads archives ...

You are completely missing the technical point here. We are
not talking about inefficient code generation, but rather a
fundamental technical issue that causes fpt code on the x86
to be seriously inefficient (by a factor of many) because
the Java spec requires checking ranges on all intermediate
results. This is very expensive, since the only way to do
this is to store every intermediate result in memory.

This is widely recognized as a flaw in the Java spec. My PhD
student Sam Figueroa, who now works at Apple, examined this
problem in detail in his recent NYU thesis. It is interesting
that the design of the ia64 floating-point unit is identical
to that of the ia32, with one exception, namely a new feature
that allows Java to be implemented efficiently.

Requiring bit-for-bit floating-point identical results sounds
good, but is far from easy to achieve.

By the way, in a recent benchmark done by one of our customers
GNAT outran a competitive compiler on Whetstones by a factor
of 2 (so I guess people's milage varies when it comes to GNAT
fpt performance). However, this is really not a relevant
comparison. In the case of Java we are talking about a
*language* feature that makes efficient fpt impossible. In
Ada, there is nothing in the language that requires inefficient
floating-point. Although it is true that the accuracy and error
checking requirements make the standard Ada generic elementary
functions package a little slower than other libraries which
do not check -- but then if this is a concern you can simply
use those other libraries.

> If you say so, it must obviously be true ... :-)

I am just reporting on our experience with users of GNAT
Professional.

> By the way, we can wonder if you have any idea of non Ada
> developments which are (from what I now ...) quite common in
> software programing.

Of the million+ lines of commercial code I have delivered in
the last 20 years on projects written just by me, only a small
fraction was in Ada, so yes, I am familiar with other languages
and what goes on in large scale software projects in all sorts
of environments.

> > A false generalization, there are many exceptions.
>
> And as usual, exceptions confirm the rule :-)
> The percentage of companies non using Ada is high enough just
> to make obvious the generalization.

Your generalization was about Ada programs as I read it, so I
do not understand that (by the way, you have garbled the idiom
here, it is "exceptions prove the rule", and the word prove
here means "test" not "proof" as in mathematics. In other
words, this idiom means that you test rules by looking for
counterexamples -- well I will have to file this along with
other entertaining "round-trip idioms" -- my favorite was
someone from France announcing that a particular task was
easy --- "a slice of pie" -- from that day on in Alsys, all
sorts of simple tasks were referred to as a "slice of pie" :-)



Sent via Deja.com
http://www.deja.com/