Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

[Marin David Condic <nobody@noplace.com>]

Jerry Coffin wrote:
> 
> I've looked.  It's usually not.  For real-time systems, the primary 
> requirement is usually for absolute predictability, NOT for maximum 
> performance.
> 
Speaking as one who does this daily in Ada, I'd take minor exception. 
Yes, *predictability* is essential and that's more an algorithmic issue 
rather than a language issue. However, don't believe for a moment that 
we don't sweat bullets over *speed* as well. When you have things that 
*must* finish in a millisecond and leave something to spare you worry 
about compiler efficiency quite a lot. Embedded, avionics quality 
compilers are typically stressing efficiency over other attributes (like 
related support tools). I've used and do use Ada compilers that are as 
good or better than those for other languages.


> 
> The last time I checked, GNAT uses the same back-end as the other GNU 
> compilers, so if it doesn't produce as good of code, it's a strong 
> indication of a performance problem in the language proper.
>  
Having used Gnat quite a bit, I'd like to know what you think it does 
that is slow. I'd be interested in some benchmark code that Gnat does 
inefficiently in comparison to similar code in C passed through gcc.

Given that I regularly use high quality Ada compilers for hard realtime 
work and have been more than satisfied with the resultant efficiency of 
the code, I'd have to say that your "strong indication of a performance 
problem in the language proper" is essentially disproven by example. Its 
an old cannard that gets regularly dragged out because people have this 
tendancy to believe unicorn stories. "My brother knows this guy who had 
a friend wo worked with this guy who used to use Ada 20 years ago and he 
said that Ada is slow, so it *must* be true..."


> 
> Though I don't work with as many Ada programmers on as regular a basis, 
> it appears to me that many do more or less the opposite: it's so widely 
> assumed that the compiler will catch almost all errors, that many 
> blithely assume that almost anything that compiles MUST be correct.  At

I work with lots of Ada programmers in a place where failure is not an 
option. We *never* blithely assume that if it compiles, its correct. We 
spend lots of time and money testing. However, in studies I've done of 
errors in Ada code versus that in other languages, you typically get a) 
fewer of them and b) of a different class. We used to get all sorts of 
errors relating to scalings on numeric values and similar sorts of 
problems that relate closely to type checking. Now, those errors all but 
disappear.

We still have errors - but they tend to be more along the lines of 
*logic* errors. No language can save you from that. The net result is 
that we save lots of money in not having to rework code and regression 
test it all because of relatively small problems that the compiler can 
catch for us. Everyone who studies "process" knows that the sooner you 
catch a problem in the production chain, the cheaper it is to fix.



> the same time, execution speed has been perceived as a problem often 
> enough that many knowingly and intentionally subvert type-checking and 
> such, on the assumption that it's necessary to get the speed they think 
> they need to be competitive.
> 
There's no way that runtime checks aren't going to cost *something*. 
However, in most apps, the cost isn't so high as to be prohibitive. When 
I build PC based apps in Ada, all the checks are left on and though 
there must be a performance hit in there somewhere, its really hard to 
see these days given the speed of your garden variety microprocessor. 
For 90% of apps it should fall below the noise floor and not matter. For 
the relatively *small* number of apps (and usually only in some critical 
places within those apps) that have a performance issue, sure - go ahead 
and turn off checks. You still get the static checks and that covers a 
lot of ground. It seems to be a non-issue to me.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================