speed of generic code in Ada (vs Java)

speed of generic code in Ada (vs Java)

[jhc0033]

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?

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

[jimmaureenrogers]

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.

Jim Rogers

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

[Ludovic Brenta]

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.

-- 
Ludovic Brenta.

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

[jhc0033]

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?

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

[Georg Bauhaus]

jhc0033@gmail.com wrote:

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

That's the point.

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

[Niklas Holsti]

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

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

[Ludovic Brenta]

jhc0033@gmail.com writes:
> Ludovic Brenta 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?

Yes, exactly.  The language allows that, and also allows the compiler
to share the object code for generics (which incurs indirection
overhead).  In practice, only one compiler shares generics while all
others will emit different (and differently optimized) object code for
each instance.

-- 
Ludovic Brenta.

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

[Gautier]

jhc0033@gmail.com wrote:

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

Exactly. For my PhD research I used generics to fill matrices with Finite 
Element integrals, whatever the format. It allowed to use the band format and 
Lapack for some problems and a sparse format and a totally different solver for 
other problems. The compiler (DEC Ada, now HP Ada) allowed to share (or not) 
generic instantiations.
AFAIK, the GNAT compiler always expands generics like macros and never shares, 
so you have something as fast as a copy-paste-modify non-generic code.
__________________________________________________________________
Gautier's Ada programming -- http://sourceforge.net/users/gdemont/

NB: For a direct answer, e-mail address on the Web site!

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

[Ivan Levashew]

Gautier пишет:
> AFAIK, the GNAT compiler always expands generics like macros and never 
> shares, so you have something as fast as a copy-paste-modify non-generic 
> code.

http://www.adacore.com/2007/12/29/NF-62-F514-002-gnat/

It is now possible to declare generic subprogram units as imported, so 
that their bodies are written in a language for which pragma Import is 
supported. This provides a limited form of generic sharing, where 
multiple instances use the same compiled body.

-- 
If you want to get to the top, you have to start at the bottom

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

[Graham]

On May 16, 7:12 pm, "jimmaureenrog...@worldnet.att.net"
<jimmaureenrog...@worldnet.att.net> wrote:
> 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.
>
> Jim Rogers

On the Java side, generics make no difference to run times, indeed (as
I remember) no difference to the generated code at all. It's the
autoboxing that slows things down - java has both an int as a primitve
type (like an Integer in Ada) and an Integer class, which contains
formatting methods and the like but which can't be used directly in an
equation. Only the Integer class can be used in Generics

Java 1.5 and above compilers allow you to use Integers where you
really mean ints - that's the autoboxing. It's generally held to be A
Bad Thing.

In any case, the 5x comparison sounds extreme and probably comes from
comparing arrays of ints with something from the Java Collection
classes, which is a bit like comparing Ada arrays with Ada Containers.
Alternatively, if you defined an Integer_Class in Ada with operators
that allowed it to be used in assigments, I imagine you'd see similar
performance hits to Java's autoboxing.

Just for balance...

Graham

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

[Robert A Duff]

Graham <graham.stark@virtual-worlds.biz> writes:

> In any case, the 5x comparison sounds extreme and probably comes from
> comparing arrays of ints with something from the Java Collection
> classes, which is a bit like comparing Ada arrays with Ada Containers.

I don't see why.  Ada.Containers.Vectors, for example, does not
introduce an extra level of indirection for each component of the
vector.  Ada is more like C++ in that regard.

> Alternatively, if you defined an Integer_Class in Ada with operators
> that allowed it to be used in assigments, I imagine you'd see similar
> performance hits to Java's autoboxing.

Right.  One problem with Java is that in many cases it forces you to
have an extra level of indirection when you don't want it.

- Bob

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccy7633br3.fsf@shell01.TheWorld.com...
> Graham <graham.stark@virtual-worlds.biz> writes:
>
>> In any case, the 5x comparison sounds extreme and probably comes from
>> comparing arrays of ints with something from the Java Collection
>> classes, which is a bit like comparing Ada arrays with Ada Containers.
>
> I don't see why.  Ada.Containers.Vectors, for example, does not
> introduce an extra level of indirection for each component of the
> vector.  Ada is more like C++ in that regard.

Sorry, but there is no language guarentee of this; it's more that an 
implementation of Ada.Containers.Vectors does not *have* to have a extra 
level of indirection. For Janus/Ada, for  instance, there would be such an 
(implicit) indirection coming from the generic code sharing even if there 
isn't any explicit one.

And I'd still expect comparisons to be slower, because the "=" code probably 
is a loop doing element comparisons (it has to use the formal "=" operator 
and cannot assume that the actual is the predefined "="). It might be 
possible for a compiler to optimize that, but it would be pretty complex to 
do so. (And even "=" for integers has to be done in a loop on some 
targets -- a bit comparison is not accurate for 1's complement machines, for 
instance.)

The net effect is that generalizations about Ada performance are probably 
not well-founded. Usually, Ada performance is similar to that of C++, but 
implementation differences can be a big deal and more different than those 
between languages.

                                 Randy.

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

[Florian Weimer]

* Ludovic Brenta:

> To add to Jim's excellent answer: Ada got it right the first time,
> back in 1980.

Huh? Ada was designed to permit both implementation models (shared and
reified generics).

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

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccy7633br3.fsf@shell01.TheWorld.com...
>> Graham <graham.stark@virtual-worlds.biz> writes:
>>
>>> In any case, the 5x comparison sounds extreme and probably comes from
>>> comparing arrays of ints with something from the Java Collection
>>> classes, which is a bit like comparing Ada arrays with Ada Containers.
>>
>> I don't see why.  Ada.Containers.Vectors, for example, does not
>> introduce an extra level of indirection for each component of the
>> vector.  Ada is more like C++ in that regard.
>
> Sorry, but there is no language guarentee of this; ...

Sure.  There's no language guarantee of anything related to efficiency.
So a programmer has to guess what typical implementations will do.
(Or measure.)  The semantics of Java require unwanted levels of
indirection, unless the compiler goes to heroic/infeasible efforts to
eliminate them.  The semantics of Ada do not.

>...it's more that an 
> implementation of Ada.Containers.Vectors does not *have* to have a extra 
> level of indirection. For Janus/Ada, for  instance, there would be such an 
> (implicit) indirection coming from the generic code sharing even if there 
> isn't any explicit one.

Right, it's a trade-off -- code sharing introduces run-time inefficiency
for the benefit of compile-time speed.  (And smaller code, which might
be more efficient in some cases.)

> And I'd still expect comparisons to be slower, because the "=" code probably 
> is a loop doing element comparisons (it has to use the formal "=" operator 
> and cannot assume that the actual is the predefined "="). It might be 
> possible for a compiler to optimize that, but it would be pretty complex to 
> do so.

I think that optimization is not too complex on a non-sharing
implementation.  If "=" happens to be the predefined one,
it can be just a bit-wise compare in many cases.

>... (And even "=" for integers has to be done in a loop on some 
> targets -- a bit comparison is not accurate for 1's complement machines, for 
> instance.)

Well, those targets are pretty rare.  More important is the fact that
floating point minus-zero and plus-zero must compare equal.

> The net effect is that generalizations about Ada performance are probably 
> not well-founded. Usually, Ada performance is similar to that of C++, but
> implementation differences can be a big deal and more different than those
> between languages.

I disagree.  Performance of Ada is pretty-close to C and C++ in most
cases.  Performance of Ada is better than Java (and Smalltalk and ...)
in most cases.  The implementation matters, but the language rules
matter more.

- Bob

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

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc1w3seile.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>> The net effect is that generalizations about Ada performance are probably
>> not well-founded. Usually, Ada performance is similar to that of C++, but
>> implementation differences can be a big deal and more different than 
>> those
>> between languages.
>
> I disagree.  Performance of Ada is pretty-close to C and C++ in most
> cases.  Performance of Ada is better than Java (and Smalltalk and ...)
> in most cases.  The implementation matters, but the language rules
> matter more.

You haven't used a wide enough variety of Ada compilers if you say that. 
Janus/Ada in particular. :-) The performance characteristics of Janus/Ada 
are very different than GNAT, on a variety of things: generics, 
discriminanted records, exceptions, tasking, just to name a few. (Sometimes 
better, sometimes worse.) Another example would be the old AdaEd compiler, 
where the result was always interpreted.

I agree that the language characteristics have a role to play (especially 
things that require dynamic memory allocation, implicitly or explicitly), 
but the implementation differences also matter a lot. I'd expect that a 
highly optimized Java JIT compiler would beat AdaEd on most measures, for 
example.

                             Randy.