Why Ada, Ada Success story?, Please read an comment

Why Ada, Ada Success story?, Please read an comment

[Matthew Jones]

A year ago we started work on a software application. It was to be
in Ada (defense market), would be realtime and use the parallel
processing. The machine that we purchsed was Unix based, shared 
memory, multi processor that would load balanced Ada tasks over
multiple processors. Well after a year we would like to be able to
claim success, but that is not exactly what we got. Note: The Ada was a
Verdix port.

After a year I came to the following conclusions:

	1. Ada compiler is good, generally not quit as fast a C
	   but really close.
	2. Text_IO is a mess.
	3. Ada Development tools especially the debugger is
	   not very good.
	4. Ada tasking runtime is a mess.
	5. Parallelism is a failure.
	6. Since C is more widely used the product generally has 
	   less bugs, and the Beta test has more participants.

	
	Discussion

1. The Ada compiler after comming out of Beta has been pretty good.
   For some proposals we compared it against C. I think this unfair
   because it causes a lowest common denominator in term of design.
   C generally won out but Ada did run faster on some machines most notably
   Ada VAX/VMS.

2. TEXT_IO generally ran slower than C printf and has alot less
   functionallity. I am willing to show examples if someone cares to
   challange this. Like write a hex dump with text_io.

3. We had a debugger called a.db and it has problems, wierd things
   happened when I stepped through instantiations of a generic.

4. The bad problems started here. It takes way to long to do a 
   rendezvous. We have just a lot more bugs in this area.

5. Even today a year after we brought Ada still load balancing on
   parallel processors doesn't work. 

6. Customer service sayes that for their products they have many more
   C customers and C is simpler therefore the product gets mature
   faster. This makes alot of sense. Consider, Microsoft I've heard
   had 50,000 beta customers for C/C++ Version7.0. How many do Alsys
   and Meridian have for their PC Ada compilers.

7. I believe someone made the claim that C++'s dynamic memory was wierd.
   While this may be true I think a similar claim can be made for Ada.
   We did a lot of dynamic memory allocation in our Ada application
   and there were raised exception and handlers at various levels,
   we found it amazingly easy to cause very hard to find problems,
   by mixing these two features.


	Questions

1. Can anyone really claim that there exists a machine that load balances
   Ada tasks over multiple processors?

2. Do or did the Ada designers have even a clue as to how parallel
   processors work? If so, why do multiprocessor venders have so much t
   rouble with Ada?

2. Does anyone NOT find Ada tasks to be too slow for realtime use?

3. Do people generally find all the advertised features to work as
   advertised?

4. Does anyone like text_io?

5. Is Verdix considered a good Ada company?

6. I thought I've read read that Ada is more consistant than other languages.
   If so, then please explain how "a: array (1..5) of integer" is okay 
   as a variable definition and not for parameter passing?

7. If anyone knows of a resource information on parallel Ada, I'd
   appreciate them litting me know.

I wish I could specify the vendor of our machine, but I feel it is
not best to do so.

Matthew Jones
jonesm@cerf.net
Litton Data Systems

Re: Why Ada, Ada Success story?, Please read an comment

[Alex Blakemore]

This posting replies to Matthew Jones Ada comments:
There is source code example at the end to counter
his claim that to write a hex dump in Ada is difficult:

-----------------

In article <1637@nic.cerf.net> jonesm@nic.cerf.net (Matthew Jones) writes:

> After a year I came to the following conclusions:
> 1. The Ada compiler after comming out of Beta has been pretty good.
>    For some proposals we compared it against C. I think this unfair
>    because it causes a lowest common denominator in term of design.
>    C generally won out but Ada did run faster on some machines most notably
>    Ada VAX/VMS.

     there are many criteria for judging a compiler, speed of generated
     code is only one: others are robustness, code size, usefulness or
     error messages and warnings, speed, interfaces to other
     tools/libraries, supporting tools, environment etc, cost etc
     correctness of generated code (PRIMARY), support for optional Ada
     features, and how it handles complex Ada features

> 2. TEXT_IO generally ran slower than C printf and has alot less
>    functionallity. I am willing to show examples if someone cares to
>    challange this. Like write a hex dump with text_io.

     text_io is only one IO package, you are free to use any other,
     Ada provides some very useful generic IO libraries sequential and
     direct_io that work with the complex or simple data type of yor
     choice,  text_io is for TEXT.  to write a hex dump, just
     instantiate sequential_io and its easy, thats what sequential_io is
     designed for, not text_io.

     sample simple hex_dump is appended to this message.

> > 3. We had a debugger called a.db and it has problems, wierd things
>    happened when I stepped through instantiations of a generic.

     a.db could use improvement


> 4. The bad problems started here. It takes way to long to do a 
>    rendezvous. We have just a lot more bugs in this area.

     how do you know, did you measure? did you buy a compiler that
     claims to be designed for real time with efficient rendezvous
     and user control over rts.  or did you buy a a generic all
     purpose Ada compiler? did you tasks poll each other or busy wait?

     designing concurrent programs is hard in any language
     rendezvous overhead is only part of the equation, it can be
     very significant or irrelevant depending upon what you are doing.

> 5. Even today a year after we brought Ada still load balancing on
>    parallel processors doesn't work. 

     the language doesnt solve every problem, does your vendor claim
     to migrate tasks for load balancing using the run time system?
     the Ada standard doesnt claim this.  if the vendor claims to do
     so, but doesnt complain to him - dont blame the language standard

> 6. Customer service sayes that for their products they have many more
>    C customers and C is simpler therefore the product gets mature
>    faster. This makes alot of sense. Consider, Microsoft I've heard
>    had 50,000 beta customers for C/C++ Version7.0. How many do Alsys
>    and Meridian have for their PC Ada compilers.

     thats true, the complexity gets pushed onto the individual
     projects, little projects are easy in C, its like a vicious
     circle - I think Ada has been severely hurt by vendors who
     thought they were done when they finished validation and
     only spent money on ports and marketing.  poor compilers gave
     Ada a bad rep which reduced the market which gave vendors less
     reason to invest which led to poor compilers getting better even 
     slower - which led back to square one.

> 7. I believe someone made the claim that C++'s dynamic memory was wierd.
>    While this may be true I think a similar claim can be made for Ada.
>    We did a lot of dynamic memory allocation in our Ada application
>    and there were raised exception and handlers at various levels,
>    we found it amazingly easy to cause very hard to find problems,
>    by mixing these two features.

     that's not Ada's fault,  dynamic memory can lead to complex
     programs.  Ada's rules about dynamic memory allocation and
     exceptions are pretty straightforward - with the exception of
     finalization which is in Ada9X. its certainly better than dealing
     with malloc and free of untyped storage.

> 1. Can anyone really claim that there exists a machine that load balances
>    Ada tasks over multiple processors?
     I thought Sequent, Encore, Alliant did
 
> 2. Do or did the Ada designers have even a clue as to how parallel
>    processors work? If so, why do multiprocessor venders have so much t
>    rouble with Ada?

     be more specific, what target are you talking about?
     multiprocessing is fairly recent, Ada certainly doesnt provide
     any more barriers than C,  what C or C++ features support this ?
     NONE, but vendors provide library routines, well why cant you
     call those routines from Ada?  if you want the Ada task semantics
     on a multiprocessor, then you do need the vendor's support
     if they dont help, you can at least do what they do in C, just
     dont use the tasking portion of the language.
 
> 2. Does anyone NOT find Ada tasks to be too slow for realtime use?

     there were just several postings of positive real time
     experiences - I dont know whether they used tasks
     YOU DONT HAVE TO USE ADA TASKS TO WRITE CONCURRENT ADA PROGRAMS
     do you read this group?

> 3. Do people generally find all the advertised features to work as
>    advertised?

     not always
 
> 4. Does anyone like text_io?

     aint perfect but yes I like it
 
> 5. Is Verdix considered a good Ada company?

     there are several others, DEC and Rational are claimed to be
     exceptional.  There are also Telsoft, Alsys, Meridian, Tartan
     and others. some focus on real time market - others on
     educational or PC market, they differ - shop around
 
> 6. I thought I've read read that Ada is more consistant than other languages.
>    If so, then please explain how "a: array (1..5) of integer" is okay 
>    as a variable definition and not for parameter passing?

     RTFM, as a variable def it defines an anonymous type,
     if you did the same thing as a parameter def, no one could
     pass anything of that anonymous type  - name your types - its not hard.

------------------- hex dump source ----------------------------------

with sequential_io,
     text_io;

procedure hex_dump is

  -- simple little hex dump to show sequential_io
  -- little formatting or efficiency changes
  -- prompt for file name because command line
  -- accessing in Ada is not terribly portable
  -- adding other options like od's -c etc aren't hard
  -- to do more formatting, you can use the 'to_string' version
  -- of text_io's put routines or 'value and then polish before output

  max_filename : constant := 200;  -- this hard coded limit can go away in 
                                   -- Ada9X, mail to ada9x-mrt@inmet.inmet.com

  units_per_line : constant := 4;  -- you choose
  output_base    : constant := 16; -- you choose again

  file_name    : string (1 .. max_filename);
  name_length  : natural;

  subtype raw_data is integer; 
  --  I would prefer 'type raw_data is range 16#00# .. 16#FF#;'
  -- but the Ada compiler I have access to currently has a problem with it :(

  package raw_io is new sequential_io (raw_data);      -- powerful Ada feature 
:)
  package hex_io is new text_io.integer_io (raw_data); -- convenient
 
  input_file         : raw_io.file_type;
  current_data       : raw_data;
  units_on_this_line : natural := 0;

begin -- hex_dump

  text_io.new_line;
  text_io.put_line ("Simple Ada hex dump");
  text_io.new_line;

  text_io.put ("File to dump => ");
  text_io.get_line (file_name, name_length);
  raw_io.open (input_file, raw_io.in_file, file_name (1 .. name_length));

  -- read some raw bits in, write some formatted ASCII out

  text_io.new_line;
  while not raw_io.end_of_file (input_file) loop
    raw_io.read (input_file, current_data);              -- simple
    hex_io.put (current_data, width => 14, base => 16);  -- solution here
    units_on_this_line := units_on_this_line + 1;
    if units_on_this_line = units_per_line then
      text_io.new_line;
      units_on_this_line := 0;
    end if;

  end loop;

  text_io.new_line;
  raw_io.close (input_file);

end hex_dump;







-- 
Alex Blakemore
alex@cs.umd.edu blakemor@marlstone.com
NeXT mail accepted