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

[Georg Bauhaus <sb463ba@user1.uni-duisburg.de>]

CTips wrote:

> 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.

Done. You might be disappointed by the results. In short:
< 1%, < 3%; and < 8% for a different program, really.

  [...]

If I run your program as an Ada program, I must use unconstrained
arrays to get a significant difference at all. And in this case I am
no longer copying the meaning of the C program. If I use arrays of known
sizes, and turn all checks ON, the Ada/C ratio is near 1.03.
Still this is certainly *not* using the C subset of Ada because the
compiler sees Ada arrays of integers, not C int[]s, it is compiling
Ada programs, using Ada rules, semantics, optimizations, passing
modes etc..

If I turn checks off then there is no more significant difference.

If I rewrite your program and actually implement a different algorithm,
as outlined in your post (unconstrained arrays),
then indeed this program runs with a slowdown of 7-8%.

But same speed of Ada and C programs doesn't mean "C subset",
since to run at about the same speed, I don't have to turn off
the checks, and I don't loos all language constructs.
If you think that a factor of 0.03 generally is an inacceptable
slowdown so no checks please etc, then I don't know what to say.
Except that marketing works this way.

gcc -W -O2 -ansi -pedantic  (C)
gnatmake -O2 -gnato -gnatE -gnatVa -fstack-check -gnatwa (Ada, checks)
gnatmake -O2 -gnatp -gnatwa  (Ada, no checks)

GCC 4.0.0, 20050215 in all cases

Here is the slow version, that is, the different algorithm, really.
The near same speed version can be obtained by shifting three
comments.

with Perms;

procedure perm_a is
    use Perms;

    perm: constant PA_Ptr := new Perm_Array(0 .. VERY_LARGE_NUMBER - 1);
    other: constant PA_Ptr := new Perm_Array(0 .. VERY_LARGE_NUMBER - 1);
    --perm: constant PA_Ptr := new Perm_Array;
    --other: constant PA_Ptr := new Perm_Array;

begin
    setup_perm(perm.all);
    do_perm(other.all, perm.all);
end Perm_A;

package Perms is

    VERY_LARGE_NUMBER: constant := 100_000_000;

    type Perm_Array is array(Natural range <>)  of Integer;
    --type Perm_Array is array(0 .. VERY_LARGE_NUMBER - 1)  of Integer;

    type PA_Ptr is access Perm_Array;

    procedure do_perm(a: out Perm_Array; perm: in Perm_Array);
    procedure setup_perm(perm: in out Perm_Array);

end Perms;


package body Perms is

    procedure do_perm(a: out Perm_Array; perm: in Perm_Array) is
    begin
       for i in perm'range loop
          a(perm(i)) := i;
       end loop;
    end do_perm;

    procedure setup_perm(perm: in out Perm_Array) is
    begin
       for i in perm'range loop
          perm(i) := i;
       end loop;
    end setup_perm;

end Perms;


> 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.

Seems not to apply here, but this is just one case. Is there
evidence of significant optimization superiority of C in the general
case?

Georg