Re: Teaching new tricks to an old dog (C++ -->Ada)

[CTips <ctips@bestweb.net>]

Georg Bauhaus wrote:

> CTips wrote:
> 
>> In fact, to get the performance similar to that which can be obtained 
>> in C, one would pretty much have to write in the C subset of Ada [i.e. 
>> turn off most of the checking, use libraries written in C + asm].
> 
> 
> Is there any significant evidence for this other than
> special cases for any of the languages discussed?

Don't have something specific to Ada, but I've seen work on PL.8, which 
had similar dynamic bounds checking. They observed, *on the average* 
about 8%, but this was on a machine with a special trap instruction for 
bounds checking. It would be closer to 15-20% if the check had to be 
done using subtract/compares/branches.

Also, other work done on bounds checking ~1990 (maybe by Rajiv Gupta) 
has numbers between 0 and 50% slowdown. And these, by the way, IIRC dont 
actually count the cost of having to use handles vs. pointers, just the 
cost of the raw access.

You can measure the slowdown yourself. Try running the following loop in 
Ada:
    void do_perm(int a[], int perm[])
    {
    int i;
    for( i = 0; i < VERY_LARGE_NUMBER; i++ )
       a[perm[i]] = i;
    }

where perm[i] is a dynamically created array, such as:
    void setup_perm(int perm[])
    {
    int i;
    for( i = 0; i < VERY_LARGE_NUMBER; i++ )
      perm[i] = i;
    }
Run the codes with and without bounds checking and see the difference.

> And why on earth should translators for programming languages
> be so dumb as to produce fast code only when the input language
> is like "the C subset"?

Because the run-time check code required by the language will require 
extra work.

> If a compiler knows about enum values and can use them in the
> construction of objects matching hardware, or of arrays of bytes,
> or whatever, why should the enum values incur a speed penalty?
> Because the compiler checks that there is static matching
> at compile time?

Compile time checks are for free ... sometimes. Be careful that you 
aren't really adding runtime checks. For instance,
    int foo(index_type i, int a[index_type'range])
    {
       ... a[i] ...
     }
will have no check, since it is guaranteed that the size of a is equal 
to the range of values of i.

However, if we now invoke this using
     int i;
     ...
     foo( (index_type)i, a);
then we (may) have to add a run-time check to see whether i is in the 
range of index_type.

There is a secondary, but fairly important affect. Compiler resources 
are finite, and compilers also suffer from "bit-rot". Roughly, you can 
only cram in so much effort into a compiler before its run-time or 
bug-rates or heuristic-balancing effort become unacceptable. In the case 
of a feature rich language like Ada (or C++), much of the effort goes 
into getting all the features right. In C, almost all the effort goes 
into the optimizations. Even when people appear to use the same backend, 
in practice, there are various optimizations which get disabled for 
non-C languages because they break at various corner cases in other 
languages.


>> And even there I'd have my doubts - given the additional features that 
>> Ada compilers have to deal with, I doubt that they would have focused 
>> as much on the optimizations.
> 
> 
> Given that the language provides
>  pragma Optimize (Time/Space/Off)
> I doubt that this general doubt can be justified.

<grin> and you are speaking from how many years of compiler development...?

>> (How can you get beaten by Python? The mind boggles!)
> 
> 
> Easy. You are not actually beaten by Python, but by a highly
> optimized C matrix library which is bound to python as an
> extension.
> If you're interested, for Ada 2005, ISO vector and matrix
> subprograms are added to the language standard.
> 
> 
> Georg