ADA on the super

ADA on the super

[Alex Stuebinger]

Hi all,

perhaps these are odd questions:
I do Symmetric Designs Search for a faculty project.
It has sth. to do with Group Theory, permutations and matrices.
ADA 83 as well as ADA 95 are my favorite languages for new implementation
projects.
I am a fanatic software engineer.
But I don't always use object oriented methods in ADA95.
I know Fortran77 but I hate it.
It's almost unreadable, if projects become large.
And the call-by-reference is difficult to debug.
I believe more in the strength of good algorithms, rather than squeezing
every bit out of the code performance, using awkward but good compiling
languages.
I speak ANSI-C better than my mother language.
I hate it, it has no abstraction.
I begin to study MPI (Snir), is there any facility to use MPI out of ADA?
Perhaps using the ADA-C interface.
Is ADA implemented on your supers?
I hate GNAT preprocessor, I love native code compilers.
Could one use ADA for a basis of a super-targeted implementation project?
Or aren't there any good vectorizing/optimizing ADA compilers out there?
Or are they too expensive?
Is ADA dead?
ADA95 is admired by many staff of the Computer Science faculty in Mainz.
Are these ignorants?
And shall we use Fortran/C till the end of times?
ADA95 is easier to learn as C++.
Performance of the two depends heavy on the implementation.
Programmes with large abstraction (operator overloading, etc) are easier to
read.
exceptions are of great importance, also rendevous tasks (on symmetric
multiprocessing
machines).
Shall we give away performance to gain abstraction?
Surely it depends on the project.
But I think ADA could be applied outside the critical systems area.
Automated subscripting checks may guarantee correct
results, which are more important than fast ones..
Please comment upon it.

I will trust on your advise, which is based on experience.
Sincerely
Alex
=======================================================
Alexander Stuebinger,
 <stuebi@mail.uni-mainz.de>,
PGP fingerprint: 8449 72C1 B3AD 5ED6 3D04 DE6B 7A66 C262 D1D2 C1B0
=======================================================

Re: ADA on the super

[Robert Dewar]

Alex, amidst a number of rather peculiar ramblings mentions

<<I hate GNAT preprocessor, I love native code compilers.
>>

Just so that this does not result in more misinformation spreading, this
is to remind that of *course* GNAT is a native code compiler and not a
"preprocessor" whatever that might mean (best guess is that Alex falls
into the common misconception of assuming that GNAT translates from
Ada to C).

Re: ADA on the super

[stuebi]

In article <dewar.892872366@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
> remind that of *course* GNAT is a native code compiler and not a
> "preprocessor" whatever that might mean

Yes, Robert I agree, but even the Free Software Foundation, doesn't
dare to call it more than a "translator" (see bulletin).
It at least shares the back end of GCC, which isn't famous for its
optimization. To say it clearly, it's strictly for the birds.

Please do not bore super users with GCC or GNAT, as they are not relevant
in this area. The theme was "ADA on the super".
On supers every nanosecond counts.

Believe me there is no such thing like a free ADA compiler.
Free software is worth every cent you pay for it.
I use commercial strength Alsys ADA (now Aonix) for several years.

I see the term "number of rather peculiar ramblings" as an offense.
Perhaps you should restrict your postings to the flame-newsgroups.

Faithfully,

Alexander

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: ADA on the super

[Robert Dewar]

<<Yes, Robert I agree, but even the Free Software Foundation, doesn't
dare to call it more than a "translator" (see bulletin).
It at least shares the back end of GCC, which isn't famous for its
optimization. To say it clearly, it's strictly for the birds.
>>

Of course it is a translator! It translates from Ada to machine language. But
in no sense is it a preprocessor (that was the term you used, and that was
just technicalloy wrong).

As for the backend of GCC, actually it is well known for high code quality
and extensive optimization. On a number of machines, GCC is the most
efficient code generator available. That certainly does not mean that GCC
will always generate faster code than competitive compilers on every 
possible program of course. However, a number of our customers chose GNAT
after extensive benchmarking *because* it was the most effective compiler
*for their application*.

That's always the point, you need to find out for yourself, with respect to
your application, which compiler will be most effective. I would recommend
basing your choice on objective tests, rather than subjective guesses.

<<Believe me there is no such thing like a free ADA compiler.
Free software is worth every cent you pay for it.
>>

We certainly hope so. It is true that GNAT is not always the cheapest Ada
solution by any means, and some of our potential customers indeed find our
prices too high and opt for cheaper solutions. Indeed, if a cheaper compiler
will do the job for you, we are the first to recommend that choice.

I do hope that you are not making the common mistake of assuming that the free
in "free software" refers to not hvaing to pay anything for it. The free is
about the freedomes that you as a customer have (in particular, the ability
to freely redistribute with or without modification). 

Too bad that English overloads the word free. In France, ACT/Europe says
"GNAT, c'est libre, mais c'est n'est pas gratuit", but that does not translate
so easily into English :-)

Robert Dewar
Ada Core Technologies

Re: ADA on the super

[K. Mathias]

Robert Dewar wrote in message ...
>As for the backend of GCC, actually it is well known for high code quality
>and extensive optimization. On a number of machines, GCC is the most
>efficient code generator available. That certainly does not mean that GCC
>will always generate faster code than competitive compilers on every
>possible program of course. However, a number of our customers chose GNAT
>after extensive benchmarking *because* it was the most effective compiler
>*for their application*.
>


See, this is where I get confused.  Looking once again at the subject line,
I can't figure out why the American Dental Association would need such
high-performance anyway!  Seems to me that a quality compiler such as GNAT
would just be overkill.


(sorry, I just couldn't resist)

<grinning widely>

- Karl Mathias

Acronyms was: ADA on the super

[Eugene Miya]

In article <6hgepl$1eh$1@camel18.mindspring.com>,
K. Mathias <kmathias@mindspring.deletethis.com> wrote:
>See, this is where I get confused.  Looking once again at the subject line,
>I can't figure out why the American Dental Association would need such
>high-performance anyway!  Seems to me that a quality compiler such as GNAT
>would just be overkill.
>(sorry, I just couldn't resist)
><grinning widely>

Hey that's okay.

As a lot of bright hardware hackers know, a modest number of their
number easily qualify the the American Disabilities Act.

We will never get away from naming collisions, but there are a few things
we can do to maintain the news group(s).

8^)

Re: ADA on the super

[Michael F Brenner]

    > Yes, Robert I agree, but ... [it] shares the back end of GCC,
    > which isn't famous for its optimization.

Robert >  ... the backend of GCC, actually it is well known for high 
       > code quality and extensive optimization. On a number of machines, 
       > GCC is the most efficient code generator available. ...
       > A number of customers chose gnat ... after extensive benchmarking
       > *because* it was the most effective compiler *for their application*.
           
I would like to confirm what Robert says in the following cases:
   (a) tsgreat, an extensive arithmetic with no I/O, is timed as follows:
       (first run tsgreat 1001 and tsgreat 1, then subtract the two numbers to
       get the time for 1000 iterations):
       
       90 MHz Pentium DOS     Alsys-83 32-bit Compiler:          25 sec 
       90 MHZ Pentium DOS     Meridian-83 32 bit Compiler:       49 sec
       90 MHz Pentium DOS     Janus-83 16 bit Compiler:          39 sec
       90 MHz Pentium DOS     gnat-95 3.10 from GWU:             21 sec
       90 MHz Pentium DOS     Turbo Pascal 7.0 32 bit Compiler:  78 sec

   (b) Lighting up things dot by dot on the SVGA memory mapped screen goes
       about twice as fast in gnat3.10 than in Alsys-83.

   (c) Lighting up things by moving large blocks or whole lines at a 
       time to the SVGA memory mapped screen goes about twice as fast in
       Alsys-83 than in gnat3.10. 

CONCLUSION: Gnat has good optimization. Gnat has good code generation
            except for packed arrays. Robert is right about bench
            marking your application with ALL of your data before 
            deciding what is fast and what is slow. 

Mike Brenner
 

Re: ADA on the super

[Robert Dewar]

<<Gnat has good optimization. Gnat has good code generation
except for packed arrays. Robert is right about bench
marking your application with ALL of your data before
deciding what is fast and what is slow.
>>

Actually, this is probably an over-generalization. Packed array stuff is
notorious, since there are so many special cases, and a given compiler
is likely to do some but not all special casing. GNAT does some packed
array stuff really efficiently, and other stuff is pretty horrible. A
good challenge is Mats Weber's

    x := x(1 .. 31) & x(0);

to do a simple rotate. It would be impressive if a compiler generated
a single rotate instruction for this -- well to be more accurate, it 
would be surprising if such an optimization came out of a general
approach (it is always easy to add one more special case). Certainly
GNAT comes *nowhere* near generating a single instruction for this
particular case.

If you are worrying about efficiency and using packed arrays other than
in the simplest manner (setting and testing bits say), you should definitely
have a look at what the compiler is doing.

One thing that is quite useful in GNAT is the capability of looking at the
generated code at the Ada source level (use the -gnatdg switch). This is
quite informative in a case like this, and much less painful than looking
at assembly language.

Re: ADA on the super

[Andi Kleen]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> <<Gnat has good optimization. Gnat has good code generation
> except for packed arrays. Robert is right about bench
> marking your application with ALL of your data before
> deciding what is fast and what is slow.
> >>
> 
> Actually, this is probably an over-generalization. Packed array stuff is
> notorious, since there are so many special cases, and a given compiler
> is likely to do some but not all special casing. GNAT does some packed
> array stuff really efficiently, and other stuff is pretty horrible. A
> good challenge is Mats Weber's
> 
>     x := x(1 .. 31) & x(0);
> 
> to do a simple rotate. It would be impressive if a compiler generated
> a single rotate instruction for this -- well to be more accurate, it 
> would be surprising if such an optimization came out of a general
> approach (it is always easy to add one more special case). Certainly
> GNAT comes *nowhere* near generating a single instruction for this
> particular case.

It is surprising that Gnat doesn't do this. At least the C frontend of gcc 
does a very similar optimization:

/* Expects sizeof(unsigned int) == 4 */
int rotate(unsigned int i)
{
	return (i << 1) | (i >> 31);
}

Compiled with -O2 on i386 Linux.

	.file	"t13.c"
	.version	"01.01"
gcc2_compiled.:
.text
	.align 4
.globl rotate
	.type	 rotate,@function
rotate:
	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
	roll $1,%eax
	leave
	ret
.Lfe1:
	.size	 rotate,.Lfe1-rotate
	.ident	"GCC: (GNU) 2.7.2.1"
	
	
-Andi	

Re: ADA on the super

[Robert Dewar]

Andi said

<<It is surprising that Gnat doesn't do this. At least the C frontend of gcc
does a very similar optimization:
>>
No, the optimization you cite is at a radically different semantic level.
There is nothing like dynamic slices and concatenations in C. If you
write Ada code that corresponds to the C code you gave, which is easy
to do, you will of course get identical code.

But there is no C code that is even vaguely like the quoted Ada code.

To get a feel for the issues involved, look at the exp_pakd unit in GNAT,
and also study some -gnatdg output, to understand the general semantic
level of the tree expansions involved here.

Remember that we are talking about very general capabilities here, which
just happen to be used in this particular case to do a rotate. 

Re: ADA on the super

[Larry Kilgallen]

In article <m3son7o2zz.fsf@fred.muc.de>, Andi Kleen <ak@muc.de> writes:

> It is surprising that Gnat doesn't do this. At least the C frontend of gcc 
> does a very similar optimization:

But what should the C front end of gcc have to do with the Ada front end
of gcc (GNAT) ?  They were written by different groups of people at 
different periods of time in different implementation languages.

Larry Kilgallen

Re: Ada on the super (packed arrays)

[Michael F Brenner]

Mike > Gnat has good optimization. Gnat has good code generation
     > except for packed arrays. Robert is right about bench
     > marking your application with ALL of your data before
     > deciding what is fast and what is slow.

Robert > Actually, this is probably an over-generalization. 
       > Packed array stuff is notorious...a good challenge is Matt Weber's
       
       >     x := x(1 .. 31) & x(0);
       
       > to do a simple rotate. 

Andi > It is surprising that Gnat doesn't do this. 
     > At least the C frontend of gcc does a very similar optimization:

        /* Expects sizeof(unsigned int) == 4 */
        int rotate(unsigned int i)
        {return (i << 1) | (i >> 31);}

        Compiled with -O2 on i386 Linux. Generated this code:
           rotate:
             pushl %ebp
             movl %esp,%ebp
             movl 8(%ebp),%eax
             roll $1,%eax
             ret

Robert (paraphrased) > [the Weber concatenation is more general than
                        the integer rotate -- comparable Ada code
                        would generate comparable assembler code]

I am trying to confirm this with comparable Ada code as follows:

    procedure tmp is
      use interfaces;
      x, y: unsigned_32 := 42;
    
      function rotate (i: unsigned_32) return unsigned_32 is
      begin
        return shift_left (i, 1) or shift_right (i, 31);
      end rotate;
    
    begin
      Y := rotate (x);
    end tmp;

Compiling it with the parameters: gcc -c -dak -O3 -gnatn -gnatp tmp.adb
for maximal optimization, the following code is generated:

File tmp.adb.sched2:

(insn:QI 4 16 14 (set (mem:SI (plus:SI (reg:SI 14 %sp)
                (const_int 100)))
        (reg:SI 2 %g2)) 106 {*movsi_insn} (nil)
    (expr_list:REG_DEAD (reg:SI 2 %g2)
        (nil)))

(insn 14 4 15 (set (reg:SI 2 %g2)
        (ashift:SI (reg/v/u:SI 24 %i0)
            (const_int 1))) 330 {ashlsi3} (insn_list:REG_DEP_ANTI 4 (nil))
    (nil))

(insn 15 14 18 (set (reg:SI 24 %i0)
        (lshiftrt:SI (reg/v/u:SI 24 %i0)
            (const_int 31))) 336 {lshrsi3} (insn_list:REG_DEP_ANTI 14 (nil))
    (expr_list:REG_DEAD (reg/v/u:SI 24 %i0)
        (nil)))

(insn 18 15 19 (set (reg/i:SI 24 %i0)
        (ior:SI (reg:SI 2 %g2)
            (reg:SI 24 %i0))) 265 {iorsi3} (insn_list 15 (insn_list 14 (nil)))
    (expr_list:REG_DEAD (reg:SI 2 %g2)
        (expr_list:REG_DEAD (reg:SI 24 %i0)
            (nil))))

This is doing two shifts and the OR operation rather than the
single rotate. 

Robert, could you please show me how to rewrite this code and how to compile
it so that it generates the rotate command instead of the two shifts
and the OR command, like gcc generates for the C command?
Thanks

Re: Ada on the super (packed arrays)

[Andi Kleen]

mfb@mbunix.mitre.org (Michael F Brenner) writes:

> Mike > Gnat has good optimization. Gnat has good code generation
>      > except for packed arrays. Robert is right about bench
>      > marking your application with ALL of your data before
>      > deciding what is fast and what is slow.
> 
> Robert > Actually, this is probably an over-generalization. 
>        > Packed array stuff is notorious...a good challenge is Matt Weber's
>        
>        >     x := x(1 .. 31) & x(0);
>        
>        > to do a simple rotate. 
> 
> Andi > It is surprising that Gnat doesn't do this. 
>      > At least the C frontend of gcc does a very similar optimization:
> 
>         /* Expects sizeof(unsigned int) == 4 */
>         int rotate(unsigned int i)
>         {return (i << 1) | (i >> 31);}
> 
>         Compiled with -O2 on i386 Linux. Generated this code:
>            rotate:
>              pushl %ebp
>              movl %esp,%ebp
>              movl 8(%ebp),%eax
>              roll $1,%eax
>              ret
> 
> Robert (paraphrased) > [the Weber concatenation is more general than
>                         the integer rotate -- comparable Ada code
>                         would generate comparable assembler code]
> 
> I am trying to confirm this with comparable Ada code as follows:
> 
>     procedure tmp is
>       use interfaces;
>       x, y: unsigned_32 := 42;
>     
>       function rotate (i: unsigned_32) return unsigned_32 is
>       begin
>         return shift_left (i, 1) or shift_right (i, 31);
>       end rotate;
>     
>     begin
>       Y := rotate (x);
>     end tmp;
> 
> Compiling it with the parameters: gcc -c -dak -O3 -gnatn -gnatp tmp.adb
> for maximal optimization, the following code is generated:
> 
> File tmp.adb.sched2:

[...]
> 
> Robert, could you please show me how to rewrite this code and how to compile
> it so that it generates the rotate command instead of the two shifts
> and the OR command, like gcc generates for the C command?

I think the real Ada way would be to use interfaces.Rotate_Left(). The C optimization
is really only a hack to cover the lack of rotate support in C.


with Interfaces; use interfaces;
with Ada.Text_IO; use Ada.Text_IO;

procedure tmp is
   x, y: unsigned_32;

   function Xinit return Unsigned_32 is -- to fool constant propagation (don't use -O3)
   begin
      return 42;
   end;

begin
   X := Xinit;
   Y := Rotate_Left(X, 1);
   Put_Line(Unsigned_32'Image(Y)); -- so that Y is not dead.
end tmp;

Compiled with gcc -S -gnatdb -O2 tmp.ada

	.file	"tmp.ada"
	.version	"01.01"
gcc2_compiled.:
.text
	.align 4
	.type	 tmp__xinit.0,@function
tmp__xinit.0:
	pushl %ebp
	movl %esp,%ebp
	subl $4,%esp
	movl %ecx,-4(%ebp)
	movl $42,%eax
	leave
	ret
.Lfe1:
	.size	 tmp__xinit.0,.Lfe1-tmp__xinit.0
	.align 4
.globl _ada_tmp
	.type	 _ada_tmp,@function
_ada_tmp:
	pushl %ebp
	movl %esp,%ebp
	subl $8,%esp
	pushl %esi
	pushl %ebx
	movl %ebp,%ecx
	call tmp__xinit.0
	movl %eax,%ebx
	rorl $31,%ebx
	call system__secondary_stack__ss_mark
	movl %eax,%esi
	leal -8(%ebp),%edx
	pushl %ebx
	pushl %edx
	call system__img_uns__image_unsigned
	movl -4(%ebp),%edx
	movl -8(%ebp),%ecx
	pushl %edx
	pushl %ecx
	call ada__text_io__put_line__2
	pushl %esi
	call system__secondary_stack__ss_release
	leal -16(%ebp),%esp
	popl %ebx
	popl %esi
	leave
	ret
.Lfe2:
	.size	 _ada_tmp,.Lfe2-_ada_tmp
	.ident	"GCC: (GNU) 2.7.2.1"


-Andi

Re: ADA on the super

[Toon Moene]

mfb@mbunix.mitre.org (Michael F Brenner) wrote:

> Robert >  ... the backend of GCC, actually it is well known for high 
> Dewar  > code quality and extensive optimization. On a number of machines, 
>        > GCC is the most efficient code generator available. ...
>        > A number of customers chose gnat ... after extensive benchmarking
>        > *because* it was the most effective compiler *for their 
application*.
>            
> I would like to confirm what Robert says in the following cases:

[ Case on 90 Mhz Pentium deleted ]

Gentlemen, please note that the subject of this thread is: Ada on the super.  
AFAIK, there are no ports of gcc (and hence, GNAT) to Cray PVP, NEC SX, 
Fujitsu VPP and other "super" gear.  A port to Cray PVP machines would be 
"interesting", as the current gcc backend doesn't even support the notion of 
an architecture not having byte addressability.

Furthermore, gcc doesn't support the OpenMP (http://www.openmp.org) 
parallellisation directives, and neither has automatic parallellisation.

Of course, it can be used with MPI (or PVM), but that requires "some more 
handy work" ;-)

-- 
Toon Moene (mailto:toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:fortran@gnu.org; NWP: http://www.knmi.nl/hirlam

Re: ADA on the super

[Larry Kilgallen]

In article <6hghkc$j8f$3@news.utrecht.NL.net>, Toon Moene <toon@moene.indiv.nluug.nl> writes:

> Gentlemen, please note that the subject of this thread is: Ada on the super.

Apparently you have not bothered to read the posts of others.  Several
have pointed out that the copies they receive say "ADA" rather than "Ada".
As for "super", that is not an abbreviation normally used here on
comp.lang.ada.  Someone tuning in in the middle might have seen your
reference to "super user", figured you were referring to Unix, and
ignored the rest.  Although I sometimes feel Robert Dewar judges posts
too harshly, his analysis of the original as "rambling" seems quite correct.

> Furthermore, gcc doesn't support the OpenMP (http://www.openmp.org)
> parallellisation directives, and neither has automatic parallellisation.

So why would one want automatic parallelization in a language devoted
to programmer-specified parallelization ?  If the problems defy manual
parallelization but are susceptible to automatic parallelization, use
a language like Fortran where automatic parallelization will not conflict
with explicit parallelization (tasking) already specified by the programmer.

In general the Ada language does not support features which cannot be used
along with particular other features.

Larry Kilgallen

Re: ADA on the super

[Toon Moene]

kilgallen@eisner.decus.org (Larry Kilgallen) wrote:

> In article <6hghkc$j8f$3@news.utrecht.NL.net>, Toon Moene 
<toon@moene.indiv.nluug.nl> writes:
> 
> > Gentlemen, please note that the subject of this thread is: Ada on the 
super.
> 
> Apparently you have not bothered to read the posts of others.  Several
> have pointed out that the copies they receive say "ADA" rather than "Ada".

I've seen them - note that there are only 17,000-something TLA's.

> As for "super", that is not an abbreviation normally used here on
> comp.lang.ada. 

OK, that explains a lot - I'm reading this in comp.sys.super, where it has a 
definite meaning.

> > Furthermore, gcc doesn't support the OpenMP (http://www.openmp.org)
> > parallellisation directives, and neither has automatic parallellisation.
> 
> So why would one want automatic parallelization in a language devoted
> to programmer-specified parallelization ? 

Because I'm reading this in comp.sys.super, and that's a reasonable thing to 
ask for an implementation of <which-ever-language> on a super computer.

Whether it'll interfere with programmer coded parallellisation - well, that's 
up to the programmer.  If I want to code explicit parallellism, I know where 
to find OCCAM :-)

-- 
Toon Moene (mailto:toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:fortran@gnu.org; NWP: http://www.knmi.nl/hirlam

Re: ADA on the super

[Greg Lindahl]

stuebi@mail.uni-mainz.de writes:

> It at least shares the back end of GCC, which isn't famous for its
> optimization.

But gcc doesn't do that badly, either. I can name quite a few existing
commercial compilers, generally ones not done by hardware vendors,
which have worse optimization than gcc. gcc even beats Digital's Alpha
Fortran compiler on one of the SPEC95 benchmarks (but loses by about
30% on the rest...) Not bad for a compiler which only recently started
to be tuned against that benchmark suite.

Does Ada have any kind of benchmark suite, preferably composed of real
applications?

> Believe me there is no such thing like a free ADA compiler.
> Free software is worth every cent you pay for it.

If you say so. I'd rather evaluate all software on a case-by-case
basis, and understand its strength and weaknesses. Huge
generalizations are usually wrong.

-- g