'Base

'Base

[ada_student]

What information does this attribute provide that cannot be specified
using other Ada attributes?

Why use an expression style to return a type? Is this because of
the presence of parameterized types(i.e. generics) in Ada?

Re: 'Base

[Matthew Heaney]

ada_student@yahoo.com wrote:
> What information does this attribute provide that cannot be specified
> using other Ada attributes?
>
> Why use an expression style to return a type? Is this because of
> the presence of parameterized types(i.e. generics) in Ada?


T'Base refers to the "base range" of the type, which defines the range
in which intermediate calculations are performed.

The standard states that the range of T'Base:

(1) includes the value 0
(2) is symmetric about zero, with possibly an extra negative value
(3) includes all of the values in the subtype T

So for example, if T is:

  type T is 1 .. 42;

then T'Base is

  type T'Base is -42 .. 42;

Note that built-in operators go through the base type, and T's "+" op
for example is implicitly declared as:

  function "+" (L, R : T'Base) return T'Base;

There are no constraint checks on T'Base, so for example:

declare
  O1 : T := T'(1) + T'(2);
  O2 : T'Base := T'(1) + T'(2)
begin

then in the first assignment to O1, there is a constraint check to
ensure that the result of 1 + 2 is in the range of T, but in the second
assignment to O2, there is no check.

T'Base is useful for generics, when you need to able to recover the
base range of the type, in order to declare a object with value 0; for
example, if this is an accumulator.

It's helpful to know something about the base range of the type, so
that you have a guarantee that you don't get any overflow during
intermediate calculations.  For example, given type T above then

procedure Op (O1, O2 : T) is
  Sum : T'Base := O1 + O2;
begin

This is a problem, since if the sum of O1 and O2 is large (that is,
greater than T'Base'Last), then you'll get overflow.  Knowing that
you're going to be adding two values together means you should declare
the type this way:

  T_Last : constant := 42;
  type T_Base is 0 .. 2 * T_Last;
  subtype T is T_Base range 1 .. T_Last;

That way you know that (sub)type T's range is 1 .. 42, but you also
have a guarantee that T'Base'Last >= 84, and hence the sum of two
values of type T cannot overflow.

Note that a declaration of the form:

  type T is range ...

actually declares a subtype, named T, of some anonymous base type.  We
can refer to the range of this base type as T'Base.

Note also that an enumeration type is its own base type, so given this
type:

  type ET is (A, B, C);

then the range of ET is the same as the range of ET'Base.  If you need
some extra literals in your "base" type, then you have to declare them
manually, not unlike what we did above:

  type ET_Base is (ET_Base_First, A, B, C, ET_Base_Last);
  subtype ET is ET_Base range A .. C;

Now you can say ET'Next (ET'Last) and you'll get a meaningful answer.
This is necessary when you do something like:

declare
  E : ET'Base := ET'First;
begin
  while E <= ET'Last then
     ... -- do something
     E := ET'Next (E);
  end loop;
end;


I might have some of the details wrong, but that's the general idea.

-Matt

Re: 'Base

[Martin Dowie]

Matthew Heaney wrote:
> T'Base refers to the "base range" of the type, which defines the range
> in which intermediate calculations are performed.
> 
> The standard states that the range of T'Base:
> 
> (1) includes the value 0
> (2) is symmetric about zero, with possibly an extra negative value
> (3) includes all of the values in the subtype T
> 
> So for example, if T is:
> 
>   type T is 1 .. 42;
> 
> then T'Base is
> 
>   type T'Base is -42 .. 42;
> 
[snip]
> I might have some of the details wrong, but that's the general idea.

Sorry Matt - you must be ill or something as you're a wee bit "off base" 
with your answer to this one!

Try this test prog to see what actually happens:

with Ada.Text_IO; use Ada.Text_IO;

procedure Test_Base is
    type T is range 1 .. 42;
begin
    Put_Line (T'Base'Image (T'Base'First));
    Put_Line (T'Base'Image (T'Base'Last));
end Test_Base;

It isn't -42 .. 42 but the 'First .. 'Last or the underlying integer 
representation. In this case (with ObjectAda) -2147483648 to 2147483647.

Cheers

-- Martin

Re: 'Base

[Martin Dowie]

Martin Dowie wrote:
> It isn't -42 .. 42 but the 'First .. 'Last or the underlying integer 

That should read "'First .. 'Last OF the"

Cheers

-- Martin

Re: 'Base

[Matthew Heaney]

Martin Dowie wrote:
>
> Sorry Matt - you must be ill or something as you're a wee bit "off base"
> with your answer to this one!
[snip]
> It isn't -42 .. 42 but the 'First .. 'Last or the underlying integer
> representation. In this case (with ObjectAda) -2147483648 to 2147483647.


I should have said that T'Base'Last is *at least* T'Last, of course it
can be larger.

However, this doesn't undermine the my point that you can only depend
on having the range guanteed by the RM, in this case -42 .. 42.

So yes it's true that your base type might include all of the values in
a 32 bit range, but that fact is irrelevant.  The range specified in
the RM is the only range that matters.

Re: 'Base

[Martin Dowie]

Matthew Heaney wrote:
> Martin Dowie wrote:
> 
>>Sorry Matt - you must be ill or something as you're a wee bit "off base"
>>with your answer to this one!
> 
> [snip]
> 
>>It isn't -42 .. 42 but the 'First .. 'Last or the underlying integer
>>representation. In this case (with ObjectAda) -2147483648 to 2147483647.
> 
> 
> 
> I should have said that T'Base'Last is *at least* T'Last, of course it
> can be larger.
> 
> However, this doesn't undermine the my point that you can only depend
> on having the range guanteed by the RM, in this case -42 .. 42.
> 
> So yes it's true that your base type might include all of the values in
> a 32 bit range, but that fact is irrelevant.  The range specified in
> the RM is the only range that matters.

I just don't see that from RM 3.5, esp para 6 - and I've been back to 
Cohen and I can't see that from page 183. I'm no Language Lawer, so 
could you please point this range guarantee out to me in the RM?

I'm having trouble seeing how your definition meets the " it is also the 
range supported at a minimum for intermediate values during the 
evaluation of expressions involving predefined operators of the type." bit.

Cheers

-- Martin

Re: 'Base

[Jeffrey R. Carter]

Martin Dowie wrote:

>>   type T'Base is -42 .. 42;
> 
> It isn't -42 .. 42 but the 'First .. 'Last or the underlying integer 
> representation. In this case (with ObjectAda) -2147483648 to 2147483647.

-42 .. 42 is the minimum range of the Base type, but since the base type for an 
integer type typically maps to something supported by the hardware, this is an 
unlikely representation.

I'm surprised ObjectAda uses 32 bits for this. GNAT 3.4.2 uses 8 bits (-128 .. 127).

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: 'Base

[Matthew Heaney]

Jeffrey R. Carter wrote:
>
> I'm surprised ObjectAda uses 32 bits for this. GNAT 3.4.2 uses 8 bits (-128 .. 127).

Exactly my point.  If you assume that you have more range than the RM
promises, then you're only asking for trouble.

-Matt

Re: 'Base

[Randy Brukardt]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:1134072443.635504.296550@g44g2000cwa.googlegroups.com...
>
> Jeffrey R. Carter wrote:
> >
> > I'm surprised ObjectAda uses 32 bits for this. GNAT 3.4.2 uses 8 bits
(-128 .. 127).
>
> Exactly my point.  If you assume that you have more range than the RM
> promises, then you're only asking for trouble.

Not quite true. The range is always going to correspond to the
representation; so unless you have to worry about non-binary machines, you
can assume the next higher power of 2 minus 1; in this case 63. Of course,
usually this isn't particularly relevant - the extra values are a small
percentage of the total.

Moreover, if you only want to worry about typical machines, then the values
are only going to be some multiple of 8-bits, so 'Base'Last can pretty much
be assumed to be the smallest value of 2**(8*N-1)-1 without trouble.

But of course the whole point of these attributes is so you don't have to
assume at all.

BTW, 'Base works on any scalar type, and the rules for floats and fixed
point types are somewhat different than described in the messages here.

And a quick answer for the OP: using 'Base is usually only needed in various
tricks. Here's one. Imagine you want a type that can hold at least 0 ..
1000, but you don't care about the exact bounds and want the most efficient
type possible. You can declare:

     type Restricted_Type is range 0 .. 1000;
     type Big_Enough_Type is range Restricted_Type'Base'First ..
Restricted_Type'Base'Last;

and Big_Enough_Type will be some full-range type appropriate for the machine
(probably 16-bits or 32-bits).

Matt gave another example. Suppose you have a generic:
    generic
       type G_Int is range <>;
    package Gen is
        ...
and you need a counter of type G_Int that starts at zero and goes to the
upper bound of G_Int. Sloppy programmers would just use G_Int for such an
counter, but that would fail if the range of G_Int didn't include zero.
Slightly less sloppy programmers would declare the counter as having the
type G_Int'Base, but that isn't going to have the overflow check. The best
solution is to declare the counter as:
     Counter : G_Int'Base range 0 .. G_Int'Last;
which ensures that 0 is included, and the right range is used. Note that
this could cover a larger range than the original type.

                                  Randy.

Avoiding constraint checks w/ 'Base

[Anonymous Coward]

In article <1134065313.469475.267400@g47g2000cwa.googlegroups.com>, 
Matthew Heaney wrote:
> 
> So for example, if T is:
> 
>   type T is 1 .. 42;
> 
> then T'Base is
> 
>   type T'Base is -42 .. 42;
> 
> Note that built-in operators go through the base type, and T's "+"
> op for example is implicitly declared as:
> 
>   function "+" (L, R : T'Base) return T'Base;
> 
> There are no constraint checks on T'Base, so for example:
> 
> declare
>   O1 : T := T'(1) + T'(2);
>   O2 : T'Base := T'(1) + T'(2)
> begin
> 
> then in the first assignment to O1, there is a constraint check to
> ensure that the result of 1 + 2 is in the range of T, but in the
> second assignment to O2, there is no check.

I like the idea of avoiding constraint checks - especially when I know
the result will be in range.  Even if I can't be sure that the sum of
the two operands is in range, it would be an advantage to be able to
handle the situation without throwing an exception.

So I have some questions.  In your example, based on what you've said
the ARM guarantees about minimal T'Base ranges, why would the
initialization for O2 go unchecked, knowing that it could just as well
go out of bounds?  Is the 'Base attribute also code for "trust me, I
know what I'm doing?"

I think it's unfortunate that the 'Base does not necessarily use the
full object size, so we are still forced to declare a new type, like
"T_Safe" in this example:

  package Base_Experiment is

     type T is range 1..42;

     function "+" (L, R : T) return T;

  end Base_Experiment;

  package body Base_Experiment is

     function "+" (L, R : T) return T is

        type T_Safe is range T'First..2 * T'Last;

        --The following use of 'Base mitigates constraint checking?
        --
        Sum : constant T_Safe'Base := T_Safe(L) + T_Safe(R);

        Return_Data : T := T'Last;

     begin

	--Do our own check if we are uncertain about the resulting
	--range.

        if Sum > T_Safe'Base(T'Last) then

           --[Take some corrective action here]--

           --The usual crash everything without a clue:
           --
           --raise Constraint_Error;

           --Give the user a reasonable chance to correct:
           --
           --raise Our_Custom_Exception;

           --Probably the best answer in most cases:
           --
           --Log_Error("Base_Experiment."+" out of bounds!");

           null;

        else

           Return_Data := T(Sum);

        end if;

        return Return_Data;
     end "+";
  end Base_Experiment;

Re: Avoiding constraint checks w/ 'Base

[Randy Brukardt]

"Anonymous Coward" <anonymous@coward.org> wrote in message
news:AL5mf.14882$H84.243@trnddc04...
> In article <1134065313.469475.267400@g47g2000cwa.googlegroups.com>,
> Matthew Heaney wrote:
> >
> > So for example, if T is:
> >
> >   type T is 1 .. 42;
> >
> > then T'Base is
> >
> >   type T'Base is -42 .. 42;
> >
> > Note that built-in operators go through the base type, and T's "+"
> > op for example is implicitly declared as:
> >
> >   function "+" (L, R : T'Base) return T'Base;
> >
> > There are no constraint checks on T'Base, so for example:
> >
> > declare
> >   O1 : T := T'(1) + T'(2);
> >   O2 : T'Base := T'(1) + T'(2)
> > begin
> >
> > then in the first assignment to O1, there is a constraint check to
> > ensure that the result of 1 + 2 is in the range of T, but in the
> > second assignment to O2, there is no check.
>
> I like the idea of avoiding constraint checks - especially when I know
> the result will be in range.  Even if I can't be sure that the sum of
> the two operands is in range, it would be an advantage to be able to
> handle the situation without throwing an exception.
>
> So I have some questions.  In your example, based on what you've said
> the ARM guarantees about minimal T'Base ranges, why would the
> initialization for O2 go unchecked, knowing that it could just as well
> go out of bounds?  Is the 'Base attribute also code for "trust me, I
> know what I'm doing?"

It's won't. The "+" operation is required to check for overflow, and if the
result isn't in the range of T'Base, that check will fail. OTOH, the
*assignment* into O2 can never fail; if "+" has generated a value, it has to
fit in O2. (Compilers are allowed to store the larger value somewhere rather
than raising an exception -- this allows optimizations -- but it isn't
allowed to store the *wrong* value - unless the checks are Suppressed.)

> I think it's unfortunate that the 'Base does not necessarily use the
> full object size, so we are still forced to declare a new type, like
> "T_Safe" in this example:

Compilers generally don't choose inefficient representations. So, in
practice, 'Base will use the full object size (certainly that is the
intent). But I don't know why the "full object size" matters in the example.
If you were runing on the U2200, a 6-bit integer is supported by the
hardware, and the compiler might have chosen that for the size of your
objects. In that case, the "full object size" isn't enough to hold your
intermediate result anyway. And while worrying about the U2200 is unlikely,
change the "42" in the example to "100", and then the example would work on
ObjectAda, but not on GNAT - because the "full object size" is 32 on OA, and
8 on GNAT.

Moral: to be totally portable, never depend on anything you know about the
hardware -- because it will (or could) change. Correlary: It's always better
to declare an appropriate type, than to depend on tricks with 'Base.

                        Randy.

Re: 'Base

[krischik]

Hi Matt

Am I allowed to copy this text to
http://en.wikibooks.org/wiki/Ada_Programming/Attributes/'Base?

Martin

Re: 'Base

[Matthew Heaney]

"krischik" <krischik@users.sourceforge.net> writes:

> Am I allowed to copy this text to
> http://en.wikibooks.org/wiki/Ada_Programming/Attributes/'Base?

Yes.  You might want to add as an addendum to what I wrote the info Randy
provided.

I've written on this topic before, back in July 2003. The subject was:

"Simple program to find average of 3 numbers"

Here's the google ref:

http://groups.google.com/group/comp.lang.ada/browse_frm/thread/30e0ceaf4e6be70c/7650c95ef9b5c7d1?lnk=st&q=sum+base+group%3Acomp.lang.ada&rnum=11&hl=en#7650c95ef9b5c7d1

That thread addresses the same issues.  Both Bob Duff and Bob Eachus
contributed, so you might want to read it too.

-Matt

Re: 'Base

[Randy Brukardt]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:uhd9ifkdp.fsf@earthlink.net...
> "krischik" <krischik@users.sourceforge.net> writes:
>
> > Am I allowed to copy this text to
> > http://en.wikibooks.org/wiki/Ada_Programming/Attributes/'Base?
>
> Yes.  You might want to add as an addendum to what I wrote the info Randy
> provided.

And you're welcome to copy my text, too.

                 Randy Brukardt.

Re: 'Base

[Martin Krischik]

ada_student@yahoo.com wrote:

> What information does this attribute provide that cannot be specified
> using other Ada attributes?

I don't know an attribute to replace 'Base. Which Attributes where you
thinking about.

> Why use an expression style to return a type? Is this because of
> the presence of parameterized types(i.e. generics) in Ada?

You can use 'Base wherever you use a Type. e.E.:

X : Natural'Base := -1;

The 'Base if Natural is Integer. It can be helpfull in generics but the use
of 'Base is not restricted to them.

Read:

http://en.wikibooks.org/wiki/Ada_Programming/Subtypes

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: 'Base

[ada_student]

Indefinite subtypes cannot be allowed under any circumstances.
It sounds like a hack just inorder to allow one class of array
object declarations into the language.

How can a statically typed language allow a type whose size is not
known at compile time?

The Java array type certainly wins over Ada in this regard.

Re: 'Base

[Pascal Obry]

ada_student@yahoo.com a �crit :
> How can a statically typed language allow a type whose size is not
> known at compile time?

By using access type (pointers).

> The Java array type certainly wins over Ada in this regard.

Java uses pointers. No magic!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: 'Base

[Matthew Heaney]

ada_student@yahoo.com writes:

> Indefinite subtypes cannot be allowed under any circumstances.

I don't understand.  What is type String?


> It sounds like a hack just inorder to allow one class of array object
> declarations into the language.

I would hardly call being able to declare strings of different lengths a hack!


> How can a statically typed language allow a type whose size is not known at
> compile time?

There's a "dope vector" associated with string objects, that describes the
length and bounds of the string.


> The Java array type certainly wins over Ada in this regard.

But array objects in Ada can be declared on the stack.  This allows you do
things like:

  procedure Op1 (N : Natural) is
    S : String (1 .. N);
  begin

  procedure Op2 (S : String) is
    S2 : String := S;
  begin

In neither case is heap necessary.  You can do this sort of thing with tagged
types too:

  procedure Op (O : T'Class) is
    O2 : T'Class := O;
  begin


One nice feature is that if you do allocate an object whose type is class-wide,
then you can initialize the object the same as in the example above:

  type T_Class_Access is access T'Class;

  procedure Op2 (O : T'Class) is
    O2 : constant T_Class_Access := new T'Class'(O);
  begin

This is built into the language; you don't need a dispatching clone method.

Re: 'Base

[ada_student]

Matthew Heaney wrote:

> ada_student@yahoo.com writes:
>
> > Indefinite subtypes cannot be allowed under any circumstances.
>
> I don't understand.  What is type String?
>

I am mistaken. Strings and Java arrays are the same(dope vectors) in
terms
of implementation. Of course, Java references always point to the heap.

Re: 'Base

[Martin Krischik]

ada_student@yahoo.com wrote:

> Indefinite subtypes cannot be allowed under any circumstances.
> It sounds like a hack just inorder to allow one class of array
> object declarations into the language.

No at all. Ada is a higher level language then C/C++ or Java. It allows for
better abstraction  which is closer to real live. In real live arrays
seldom beginn with zero:

Weekdays 1 .. 7
Month 1 .. 31
Year 1 .. 366

Ada allows integer and array type for all those circumstances.

> How can a statically typed language allow a type whose size is not
> known at compile time?

Quite easily. The size is just calculated at run time and the memory needed
is then allocated staticly, on stack or on heap. The actual size becomes
part of the array itself.

In lower level languages this tedious work is dumped onto the programmer. 

> The Java array type certainly wins over Ada in this regard.

Really? How about:

type Historic_Data is array (-6000 .. 2005) of Data_Entry;

Java (and C/C++) only have zero based arrays. In my eye that allway looses
over abritary array bound. "Off by one error" is a well known term in those
languages. 

To represent an Ada array in Java you would need:

class Array_Type
   {
   private int First;
   private int Last;
   private Data Elements [];

   Data get_Element (int Index)
     {
     if (Index > First) then throw ....
     if (Index < Last) then throw ....
     return Data [Index - First];
     } 
   }

Ada arrays are not a primitive type - they are a quite complex and powerfull
type.

Performace? Ada allways outperform Java for a start. But Ada's build in
checks will also outperform C/C++ when used with all appropriate
"assert()"s in place.

For details on why read:

http://en.wikibooks.org/wiki/Computer_programming/Error_handling
http://en.wikibooks.org/wiki/Ada_Programming/Error_handling

Especially chapter 5 on "Design by Contract".

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: 'Base

[Larry Kilgallen]

In article <1170126.PvJVGQkA4J@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:
> ada_student@yahoo.com wrote:
> 
>> Indefinite subtypes cannot be allowed under any circumstances.
>> It sounds like a hack just inorder to allow one class of array
>> object declarations into the language.
> 
> No at all. Ada is a higher level language then C/C++ or Java. It allows for
> better abstraction  which is closer to real live. In real live arrays
> seldom beginn with zero:
> 
> Weekdays 1 .. 7
> Month 1 .. 31
> Year 1 .. 366

Only for students of early Christianity.

Re: 'Base

[Björn Persson]

Larry Kilgallen wrote:
> In article <1170126.PvJVGQkA4J@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:
>>Weekdays 1 .. 7
>>Month 1 .. 31
>>Year 1 .. 366
> 
> Only for students of early Christianity.

Maybe Martin counts years since the birth of Alan Turing? ;-)

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: 'Base

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Larry Kilgallen wrote:
>> In article <1170126.PvJVGQkA4J@linux1.krischik.com>, Martin Krischik
>> <krischik@users.sourceforge.net> writes:
>>>Weekdays 1 .. 7
>>>Month 1 .. 31
>>>Year 1 .. 366
>> 
>> Only for students of early Christianity.
> 
> Maybe Martin counts years since the birth of Alan Turing? ;-)

Well, that what comes when one is lazy in coosing this variable/type names.
Should have use Day_of_Year.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: 'Base

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <1170126.PvJVGQkA4J@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:
> > ada_student@yahoo.com wrote:
> > 
> >> Indefinite subtypes cannot be allowed under any circumstances.
> >> It sounds like a hack just inorder to allow one class of array
> >> object declarations into the language.
> > 
> > No at all. Ada is a higher level language then C/C++ or Java. It allows for
> > better abstraction  which is closer to real live. In real live arrays
> > seldom beginn with zero:
> > 
> > Weekdays 1 .. 7
> > Month 1 .. 31
> > Year 1 .. 366
> 
> Only for students of early Christianity.

Really?  Were there 31 months back then?

;-) ;-) 

- Bob

Re: 'Base

[Martin Krischik]

Larry Kilgallen wrote:

> In article <1170126.PvJVGQkA4J@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes:
>> ada_student@yahoo.com wrote:
>> 
>>> Indefinite subtypes cannot be allowed under any circumstances.
>>> It sounds like a hack just inorder to allow one class of array
>>> object declarations into the language.
>> 
>> No at all. Ada is a higher level language then C/C++ or Java. It allows
>> for
>> better abstraction  which is closer to real live. In real live arrays
>> seldom beginn with zero:
>> 
>> Weekdays 1 .. 7
>> Month 1 .. 31
>> Year 1 .. 366
> 
> Only for students of early Christianity.

Well I was lazy and did not want to type Day_Of_Month. I hope the OP still
got the drift.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: 'Base

[Ole-Hjalmar Kristensen]

My gut reaction was also that Ada will always outperform Java, but I
have found at least one case there this is not true.  I recently wrote
a simple test program to transpose a two-dimensional array in Java,
Ada, C++, and C. The purpose was not really to compare languages, but
to see the effects of caching. There were two different alogrithms
used, one a simple nested loop, the other a recursive subdivision with
a nested loop at the lowest level. When the simple nested loop was
tested with large data sets (~ available RAM on the machines) the
diffence between Ada, C, and C++ was insignificant, all being 3-4
times faster than Java. However, when testing the recursive version, I
found that Java was actually about 10% faster than the other three,
which again came extremely close to each other. Apparently the JIT
compiler had plenty of time to do its work and come up with pretty
optimal code. The other interesting result from the experiment was
that the recursive  version was from 3-4 to 20 times faster than the
simple nested loop.


>>>>> "MK" == Martin Krischik <krischik@users.sourceforge.net> writes:
<snip>
    MK> Ada arrays are not a primitive type - they are a quite complex and powerfull
    MK> type.

    MK> Performace? Ada allways outperform Java for a start. But Ada's build in
    MK> checks will also outperform C/C++ when used with all appropriate
    MK> "assert()"s in place.

<snip>
-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: 'Base

[Martin Krischik]

Ole-Hjalmar Kristensen wrote:

> My gut reaction was also that Ada will always outperform Java, but I
> have found at least one case there this is not true.  I recently wrote
> a simple test program to transpose a two-dimensional array in Java,
> Ada, C++, and C. The purpose was not really to compare languages, but
> to see the effects of caching. There were two different alogrithms
> used, one a simple nested loop, the other a recursive subdivision with
> a nested loop at the lowest level. When the simple nested loop was
> tested with large data sets (~ available RAM on the machines) the
> diffence between Ada, C, and C++ was insignificant, all being 3-4
> times faster than Java. However, when testing the recursive version, I
> found that Java was actually about 10% faster than the other three,
> which again came extremely close to each other. Apparently the JIT
> compiler had plenty of time to do its work and come up with pretty
> optimal code. The other interesting result from the experiment was
> that the recursive  version was from 3-4 to 20 times faster than the
> simple nested loop.

Interesting.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: 'Base

[tmoran]

>> a simple test program to transpose a two-dimensional array in Java,
>> Ada, C++, and C. The purpose was not really to compare languages, but
>> to see the effects of caching. There were two different alogrithms
>> used, one a simple nested loop, the other a recursive subdivision with
  I'd be interested in seeing/trying the code.

Re: 'Base

[Georg Bauhaus]

Ole-Hjalmar Kristensen wrote:

> There were two different alogrithms
> used, one a simple nested loop, the other a recursive subdivision with
> a nested loop at the lowest level.

Have you tried this with Intel's compiler, too? It can do
something about tail calls.

-- Georg 

Re: 'Base

[Per Sandberg]

Ole-Hjalmar Kristensen wrote:
> My gut reaction was also that Ada will always outperform Java, but I
> have found at least one case there this is not true.  I recently wrote
> a simple test program to transpose a two-dimensional array in Java,
> Ada, C++, and C. The purpose was not really to compare languages, but
> to see the effects of caching. There were two different alogrithms
> used, one a simple nested loop, the other a recursive subdivision with
> a nested loop at the lowest level. When the simple nested loop was
> tested with large data sets (~ available RAM on the machines) the
> diffence between Ada, C, and C++ was insignificant, all being 3-4
> times faster than Java. However, when testing the recursive version, I
> found that Java was actually about 10% faster than the other three,
> which again came extremely close to each other. Apparently the JIT
> compiler had plenty of time to do its work and come up with pretty
> optimal code. The other interesting result from the experiment was
> that the recursive  version was from 3-4 to 20 times faster than the
> simple nested loop.
> 
> 
> 
>>>>>>"MK" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
> <snip>
>     MK> Ada arrays are not a primitive type - they are a quite complex and powerfull
>     MK> type.
> 
>     MK> Performace? Ada allways outperform Java for a start. But Ada's build in
>     MK> checks will also outperform C/C++ when used with all appropriate
>     MK> "assert()"s in place.
> 
> <snip>

This is intresting but i have tried Ada (GNAT/GCC) with different 
optimisation levels and different validity checking.
and fount that ther is a clearly visible diference in performance 
depending on how far the compiler is allowed to go in terms of optimisation.
I have not done any qualified measurments but the guts feeling is that 
the performace may change bye a factor of at least 2 depending on 
compiler switches.
Also worth to mention that as far as i have seen ther is normaly areound 
30% difference in performace when going from "-O0" to "-Os".

/Per

Re: 'Base

[Martin Krischik]

Per Sandberg wrote:

> Ole-Hjalmar Kristensen wrote:
>> My gut reaction was also that Ada will always outperform Java, but I
>> have found at least one case there this is not true.  I recently wrote
>> a simple test program to transpose a two-dimensional array in Java,
>> Ada, C++, and C. The purpose was not really to compare languages, but
>> to see the effects of caching. There were two different alogrithms
>> used, one a simple nested loop, the other a recursive subdivision with
>> a nested loop at the lowest level. When the simple nested loop was
>> tested with large data sets (~ available RAM on the machines) the
>> diffence between Ada, C, and C++ was insignificant, all being 3-4
>> times faster than Java. However, when testing the recursive version, I
>> found that Java was actually about 10% faster than the other three,
>> which again came extremely close to each other. Apparently the JIT
>> compiler had plenty of time to do its work and come up with pretty
>> optimal code. The other interesting result from the experiment was
>> that the recursive  version was from 3-4 to 20 times faster than the
>> simple nested loop.
>> 
>> 
>> 
>>>>>>>"MK" == Martin Krischik <krischik@users.sourceforge.net> writes:
>> 
>> <snip>
>>     MK> Ada arrays are not a primitive type - they are a quite complex
>>     and powerfull MK> type.
>> 
>>     MK> Performace? Ada allways outperform Java for a start. But Ada's
>>     build in MK> checks will also outperform C/C++ when used with all
>>     appropriate MK> "assert()"s in place.
>> 
>> <snip>
> 
> This is intresting but i have tried Ada (GNAT/GCC) with different
> optimisation levels and different validity checking.
> and fount that ther is a clearly visible diference in performance
> depending on how far the compiler is allowed to go in terms of
> optimisation. I have not done any qualified measurments but the guts
> feeling is that the performace may change bye a factor of at least 2
> depending on compiler switches.
> Also worth to mention that as far as i have seen ther is normaly areound
> 30% difference in performace when going from "-O0" to "-Os".

Sure - if you switch checks off and optimization on the program will be
faster.

If you compare Ada - with checks - with C/C++ - with assert then Ada will
have more change in optimization of those checks then C/C++ has on the
asserts.

Ada:

type X is range ...

f (Value : X) is ....

for I in X'Range loop
  f (i);
end loop;

C:

typedef int X;

extern f (X Value)
  {
  assert (Value >= X_First && Value <= X_Last)

  .....
  }

for (i= X_First ; X <= X_Last; i++)
  {
  f (i);
  }

Ada will make no checks at all while in C must check "Value" with each loop.

Remember: we live in a complex world and f () will be called a different
places - some where static analysis may prove the correctness of t the
parameter - like the example above - and some where it cant. Just removing
the assert is not an option.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: 'Base

[Jeffrey R. Carter]

Martin Krischik wrote:

> for I in X'Range loop

for I in X loop

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

Re: 'Base

[Martin Krischik]

Jeffrey R. Carter wrote:

> Martin Krischik wrote:
> 
>> for I in X'Range loop
> 
> for I in X loop

Ups. Thanks.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com