Re: speed of generic code in Ada (vs Java)

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

jhc0033@gmail.com wrote:
> On May 16, 11:54 am, Ludovic Brenta <ludo...@ludovic-brenta.org>
> wrote:
> 
>>jimmaureenrogers writes:
>>
>>>On May 16, 11:31 am, "jhc0...@gmail.com" <jhc0...@gmail.com> wrote:
>>>
>>>>Java only allows 'objects' as generics parameters. So, if you define a
>>>>generic class and use 'Integer' as a parameter, your code will be slow
>>>>because of the boxing - up to 5x compared to non-generic Int (see the
>>>>recent discussion in comp.lang.java.programmer - the 'numerics'
>>>>thread). Is the situation similar with generics in Ada, GNAT,
>>>>specifically?
>>
>>>No.
>>
>>To add to Jim's excellent answer: Ada got it right the first time,
>>back in 1980.
>>
> 
> 
> So, if I write a, say, linear equation solver using generics in Ada,
> and then instantiate it with single precision, double precision,
> complex number single precision and complex number double precision,
> you'd expect it to be as fast as the equivalent non-generic versions?

In general, that would depend on how your Ada compiler implements 
generics. There are two basic ways:

- Shared code: The compiler generates code from the generic itself, 
and each instance uses the same code. This code must then be very 
parametric and flexible to handle all kinds of instances, and will 
often be slower than a non-generic version. On the other hand, you 
can make many instances without adding (much) code to the executable.

- Instance-specific code: The compiler generates code for each 
instance, using the particular actual parameters of the instance, 
in a "macro" fashion. An instance is likely to be as fast as a 
non-generic version, but each instance adds a (specialized) copy of 
the whole generic code to the executable.

Shared-code generics were more popular in the past, when computers 
had small memories. Some compilers still provide them. I believe 
GNAT uses instance-specific code always, so genericity should not 
reduce computation speed with GNAT.

In your example of a linear equation solver (LES), since it needs 
instances with both "real" and "complex" numbers, the generic 
formal "number" type cannot be declared as a numeric type (with 
predefined "+", "-", etc.). The formal type must be declared as 
"private", and the required arithmetic operators "+", "-", etc. 
must be generic formal suprograms.

On a processor with native floating-point instructions I would 
expect a shared-code generic LES to be slower than a non-generic 
LES for "real" numbers, because the non-generic form could directly 
use in-line floating-point instructions (of the proper single or 
double precision) while the generic code has to call the operator 
subprograms for the actual type.

For "complex" numbers I would expect even a shared-code generic to 
be about as fast as a non-generic version, because both forms must 
in principle call the operator subprograms from 
Ada.Numerics.Xxx_Complex_Types. However, in the non-generic form 
the compiler could use in-lining or special-case optimizations for 
Ada.Numerics.XXx_Complex_Types to avoid these calls, which could 
make the non-generic form faster.

A generic LES with instance-specific code should be as fast as a 
non-generic version for any kind of "number".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .