Re: Ada versus Java - Tasking

Re: Ada versus Java - Tasking

[Brad Balfour]

In article <01bc03ee$594dc520$829d6482@joy.ericsson.se>, "Jonas Nygren"
<ehsjony@ehs.ericsson.se> wrote:

>I have written a small producer-consumer type of program
>both in Ada and Java. To my astonishment the Java code
>executes faster than the Ada code.
>
>My test starts 50 producer-consumer pairs that run in
>parallell. Each pair produces/consumes 1000 messages
>of 50 bytes. I get the following timing on my P133,
>16M, and running Win95:
>
>Ada  (Gnat 3.04a)  : ~30 s
>Java (MS SDK-Java) : ~15 s
>
>This result was very much to my surprise!

It would help if you posted a copy of both programs. That we we could
understand your implementations and see if they are truly comperable.
There are several ways you could create producer/consumers in Ada 95.

Brad

-- 
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
3930 Pender Drive     Fairfax, VA 22030
   "...they even have rules for exceptions" -- Dewar and Schonberg

Re: Ada versus Java - Tasking

[wiljan]

Jonas Nygren <ehsjony@ehs.ericsson.se> wrote in article
<01bc03ee$594dc520$829d6482@joy.ericsson.se>...
> I have tried to check over and over and I can not find
> any errors in my code. Furthermore, with Java I managed
> to start 400 producer-consumer pairs but the Ada version
> stopped working already when 63 pairs were started
> (62 pairs would run).
Address space is limited on NT that is way only 125 tasks.
By default gnat 304 links with -stack 0x1000000,0x10000
This meants that the stack reserve size is 0x1000000.
Since the user address space size is only 0x80000000 maximum
128 stacks for tasks kan be reserved. Thats way the limit of
about 125 tasks.

If you change this into a smaller stack reserve size then you
will be able to create many tasks in your ada program.

The -stack option can be found in the file specs.

Wiljan

Ada versus Java - Tasking

[Jonas Nygren]

I have written a small producer-consumer type of program
both in Ada and Java. To my astonishment the Java code
executes faster than the Ada code.

My test starts 50 producer-consumer pairs that run in
parallell. Each pair produces/consumes 1000 messages
of 50 bytes. I get the following timing on my P133,
16M, and running Win95:

Ada  (Gnat 3.04a)  : ~30 s
Java (MS SDK-Java) : ~15 s

This result was very much to my surprise!

I have tried to check over and over and I can not find
any errors in my code. Furthermore, with Java I managed
to start 400 producer-consumer pairs but the Ada version
stopped working already when 63 pairs were started
(62 pairs would run).

What is a reasonable explanation to this result. Both
Gnat and Java run on top of Win95's threads so there must
be something else that differs. It might be that Gnat 3.04a
is a bit dated and that the implementation in Win95 isn't
so good. It could also be that Ada tasking is inherently
'heavier' than Java's and that this accounts for the
differences.

I would be interested to understand this better if you have
any idea what is happening here. 

/jonas

Re: Ada versus Java - Tasking

[Steve Doiel]

In article <01bc03ee$594dc520$829d6482@joy.ericsson.se>, 
ehsjony@ehs.ericsson.se says...
>
>
>I have written a small producer-consumer type of program
>both in Ada and Java. To my astonishment the Java code
>executes faster than the Ada code.
>
[snip]
>
>I would be interested to understand this better if you have
>any idea what is happening here. 
>
>/jonas

Have you tried setting the optimization level for GNAT to
-O3 as well as turning off all runtime checks?  I have seen
this make a significant difference in the speed of Ada (and
GNU C).

Steve Doiel

Re: Ada versus Java - Tasking

[Jeff Carter]

Jonas Nygren wrote:
> 
> I have written a small producer-consumer type of program
> both in Ada and Java. To my astonishment the Java code
> executes faster than the Ada code.
> 
> My test starts 50 producer-consumer pairs that run in
> parallell. Each pair produces/consumes 1000 messages
> of 50 bytes. I get the following timing on my P133,
> 16M, and running Win95:
> 
> Ada  (Gnat 3.04a)  : ~30 s

This seems excessive; see below.

> Java (MS SDK-Java) : ~15 s
> 
> ...
>
> ... the Ada version
> stopped working already when 63 pairs were started
> (62 pairs would run).

I too encountered this limitation.

Here's my version:

with Interfaces;
with Ada.Calendar;
with Ada.Text_Io;
 
use Ada;
procedure Prod_Cons is
   procedure Time_This is
      type Data_Block is array (1 .. 50) of Interfaces.Unsigned_8;
      for Data_Block'Component_Size use Interfaces.Unsigned_8'Size;
      for Data_Block'Size use 50 * Interfaces.Unsigned_8'Size;
   
      task type Consumer_Agent is
         entry Put (Data : in Data_Block);
      end Consumer_Agent;
      type Consumer_Ptr is access all Consumer_Agent;
   
      task type Producer_Agent (Consumer : access Consumer_Agent);
      type Producer_Ptr is access all Producer_Agent;
   
      task body Consumer_Agent is
         Local : Data_Block;
      begin -- Consumer_Agent
         Forever : loop
            select
               accept Put (Data : in Data_Block) do
                  Local := Data;
               end Put;
            or
               terminate;
            end select;
         end loop Forever;
      end Consumer_Agent;
   
      task body Producer_Agent is
         Data : Data_Block := (others => 0);
      begin -- Producer_Agent
         All_Data : for I in 1 .. 1000 loop
            Consumer.Put (Data => Data);
         end loop All_Data;
      end Producer_Agent;
   
      Consumer : Consumer_Ptr;
      Producer : Producer_Ptr;
   begin -- Time_This
      All_Pairs : for I in 1 .. 50 loop
         Consumer := new Consumer_Agent;
         Producer := new Producer_Agent (Consumer => Consumer);
      end loop All_Pairs;
   end Time_This;
   
   Stop  : Calendar.Time;
   Start : Calendar.Time := Calendar.Clock;
   
   use type Calendar.Time;
begin -- Prod_Cons
   Time_This;
   Stop := Calendar.Clock;
   Text_Io.Put_Line (Duration'Image (Stop - Start) );
end Prod_Cons;

Here are some typical outputs:

C:\ada>prod_cons
 18.340000000
 
C:\ada>prod_cons
 18.180000000
 
C:\ada>prod_cons
 19.170000000
 
C:\ada>prod_cons
 18.120000000
 
C:\ada>prod_cons
 19.660000000
 
C:\ada>prod_cons
 17.850000000
 
C:\ada>prod_cons
 17.630000000
 
C:\ada>prod_cons
 18.010000000

These give an average of 18.37 seconds per run. While not as good as 15
seconds, this is better than 30 seconds.

These figures are for GNAT 3.04a on a P120, 32MB, Win95. Built using

   gnatmake -O3 -gnatn prod_cons.adb

I conclude the 62-pair limitation is not related to amount of memory.

I would be interested in knowing how Jonas' version differs from mine.
-- 
Jeff Carter
Innovative Concepts, Inc.

Re: Ada versus Java - Tasking

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <32DFC320.41C67EA6@innocon.com> Jeff Carter <carter@innocon.com> writes:

< Stuff deleted>

   Here are some typical outputs:

   C:\ada>prod_cons
    18.340000000

   C:\ada>prod_cons
    18.180000000

   C:\ada>prod_cons
    19.170000000

   C:\ada>prod_cons
    18.120000000

   C:\ada>prod_cons
    19.660000000

   C:\ada>prod_cons
    17.850000000

   C:\ada>prod_cons
    17.630000000

   C:\ada>prod_cons
    18.010000000

   These give an average of 18.37 seconds per run. While not as good as 15
   seconds, this is better than 30 seconds.

   These figures are for GNAT 3.04a on a P120, 32MB, Win95. Built using

      gnatmake -O3 -gnatn prod_cons.adb

   I conclude the 62-pair limitation is not related to amount of memory.

   I would be interested in knowing how Jonas' version differs from mine.
   -- 
   Jeff Carter
   Innovative Concepts, Inc.


These task switching times are still pretty horrible though. Using
Unix processes and pipes or System V message queues, you can do just
as well. Any idea of why this is so? Does it follow from the
definition of an Ada task, or is it just this particular
implementation.
 
With a task switching overhead of this magnitude, tasks become
unattractive as a way of programs dealing with high-speed IO, for
example.

Re: Ada versus Java - Tasking

[Robert A Duff]

In article <OHK.97Jan18194202@ultra.tfdt-o.nta.no>,
Ole-Hjalmar Kristensen FOU.TD/DELAB <ohk@ultra.tfdt-o.nta.no> wrote:
>These task switching times are still pretty horrible though. Using
>Unix processes and pipes or System V message queues, you can do just
>as well. Any idea of why this is so? Does it follow from the
>definition of an Ada task, or is it just this particular
>implementation.

No, it's not hard to make task switching fast, if you're willing to give
up the idea that every Ada task should map onto exactly one OS
task/thread.  But there are some advantages to that one-for-one mapping,
despite the HUGE performance penalty.  E.g., when a task does a blocking
system call, it's nice if some other task gets to run while it's
waiting.  Making that happen is hard (but I don't think impossible!)
unless each Ada task maps to an OS task (thread).  And if the OS threads
are horribly slow (which is often the case), then tough luck.

>With a task switching overhead of this magnitude, tasks become
>unattractive as a way of programs dealing with high-speed IO, for
>example.

Indeed.

- Bob

Re: Ada versus Java - Tasking

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <E48D1A.1sL@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

   In article <OHK.97Jan18194202@ultra.tfdt-o.nta.no>,
   Ole-Hjalmar Kristensen FOU.TD/DELAB <ohk@ultra.tfdt-o.nta.no> wrote:
   >These task switching times are still pretty horrible though. Using
   >Unix processes and pipes or System V message queues, you can do just
   >as well. Any idea of why this is so? Does it follow from the
   >definition of an Ada task, or is it just this particular
   >implementation.

   No, it's not hard to make task switching fast, if you're willing to give
   up the idea that every Ada task should map onto exactly one OS
   task/thread.  But there are some advantages to that one-for-one mapping,
   despite the HUGE performance penalty.  E.g., when a task does a blocking
   system call, it's nice if some other task gets to run while it's
   waiting.  Making that happen is hard (but I don't think impossible!)
   unless each Ada task maps to an OS task (thread).  And if the OS threads
   are horribly slow (which is often the case), then tough luck.

   >With a task switching overhead of this magnitude, tasks become
   >unattractive as a way of programs dealing with high-speed IO, for
   >example.

   Indeed.

   - Bob

I think I would be willing to give up the idea that every Ada task
should map onto exactly one OS task/thread. In my (admittedly limited)
experince with POSIX threads, you are not able to get the same amount
of overlapping IO as by using explicit asynchronous read/write
calls. My tests have been limited to SunOS and HP-UX, but I suspect
most other thread implementations will give similar results. A POSIX
thread will be suspended if the device is not ready, ans as you say,
other threads may run while the suspended thread is waiting. However,
my tests indicate that while the (blocking) read/write call is
executed, the whole OS process is suspended. At least, if you have two
threads doing IO on separate devices, you will not get any overlap of
those IO operations. In other words, using a native thread package
does not automagically transform normal blocking read/write calls into
asynchronous calls, which I find quite reasonable.

At best, the native threads give very vague promises about the degree
of real concurrency, so if I have to choose, I would rather have fast
task switching and handle any blocking system calls myself.

The new protected types seem really promising, though.

Ole-Hj. Kristensen

Re: Ada versus Java - Tasking

[Larry Kilgallen]

In article <OHK.97Jan19133540@ultra.tfdt-o.nta.no>, ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

> calls. My tests have been limited to SunOS and HP-UX, but I suspect
> most other thread implementations will give similar results. A POSIX
> thread will be suspended if the device is not ready, ans as you say,
> other threads may run while the suspended thread is waiting. However,
> my tests indicate that while the (blocking) read/write call is
> executed, the whole OS process is suspended. At least, if you have two
> threads doing IO on separate devices, you will not get any overlap of
> those IO operations. In other words, using a native thread package
> does not automagically transform normal blocking read/write calls into
> asynchronous calls, which I find quite reasonable.
> 
> At best, the native threads give very vague promises about the degree
> of real concurrency, so if I have to choose, I would rather have fast
> task switching and handle any blocking system calls myself.

What guarantees are provided vary not only among operating systems but
also among versions of a given operating system.  Alpha VMS, for instance,
has seen dramatic increases in parallelism up through V7.1 which
just arrived this week.  Conventional wisdom is that this was due
in no small part to competition from Windows NT.  VMS was the
first of the three commercial Alpha operating systems to support
multiprocessors and the last to support scheduling of threads
from a single process simultaneously onto those multiple processors.

Operating system developers have a much better chance to make the
scheduling interact with the hardware properly, so I think the better
choices are:

	1) Rely on OS threading support, and wait for improvements.

	2) Lobby the operating system provider for better support,
	   using all methods available, including examples of other
	   operating systems which do it better, either on the same
	   hardware or some other hardware.

Larry Kilgallen

Re: Ada versus Java - Tasking

[David Taylor]

In article <32DFC320.41C67EA6@innocon.com>, Jeff Carter <carter@innocon.com>
wrote:

>Jonas Nygren wrote:
>> 
>> I have written a small producer-consumer type of program
>> both in Ada and Java. To my astonishment the Java code
>> executes faster than the Ada code.
>> 
>> My test starts 50 producer-consumer pairs that run in
>> parallell. Each pair produces/consumes 1000 messages
>> of 50 bytes. I get the following timing on my P133,
>> 16M, and running Win95:
>> 
>> Ada  (Gnat 3.04a)  : ~30 s
>
>This seems excessive; see below.
>
>> Java (MS SDK-Java) : ~15 s
>> 
>> ...
>>
>> ... the Ada version
>> stopped working already when 63 pairs were started
>> (62 pairs would run).
>
>I too encountered this limitation.
>
>Here's my version:
>
 << Ada source omitted >>

<< timings omitted >>

>These give an average of 18.37 seconds per run. While not as good as 15
>seconds, this is better than 30 seconds.
>These figures are for GNAT 3.04a on a P120, 32MB, Win95. Built using
>   gnatmake -O3 -gnatn prod_cons.adb
>I conclude the 62-pair limitation is not related to amount of memory.
>I would be interested in knowing how Jonas' version differs from mine.
>-- 
>Jeff Carter
>Innovative Concepts, Inc.

As I was reading this post, I wondered how these timings would compare with
a lowly Apple 120MHz 604 running GNAT 3.07 on top of MachTen.  Some numbers
I got using the same gnatmake above were:

home/dave/prod> prod_cons
 4.916670000
/home/dave/prod> prod_cons
 5.000000000
/home/dave/prod> prod_cons
 5.066664000
/home/dave/prod> prod_cons
 4.583350000
/home/dave/prod> prod_cons
 4.699972000
/home/dave/prod> prod_cons
 4.566644000
/home/dave/prod>

Since the processors are comparable, I suspect the most improvement in time
is because of 3.07.  I no longer have 3.05 installed, so I can't check the
timing with it.  Anyway, not too shabby.

Dave

Re: Ada versus Java - Tasking

[Tom Moran]

> These task switching times are still pretty horrible though
Yes, and Win95 takes (on my P60) over 700 microseconds just to call
Ada.Calendar.Clock
  You can use an Ada compiler that doesn't map tasks to OS threads or,
for really fast stuff, use DOS (where the OS doesn't get in the way).

Re: Ada versus Java - Tasking

[Michael Paus]

jhopper@erinet.com (Jim Hopper) wrote:
[...]
> 
> 
> Dave,
> 
> no these times are better because the 604e at the same clock speed is
> faster than a pentium pro at the same clock speed (byte magazine
> article recently) and much faster than a pentium.  a 603e is roughly
> equal to a pentium at same clock speed.
> 
> The piwg benchmarks as i recall showed no gain in performace between
> 3.05 and 3.07 in this area.  (i could be wrong its been several months
> since i looked at the numbers).  another interesting thing from the
> piwgs (i have the graphs for these) is that my 120 mhz 8500 beats our
> 150 mhz SGI indy in most all piwg tests, and my 180mhz upgrade to the
> same 8500 boosted it to the point where it beats out our 250mhz onyx in
> most all tests.
> 
> jim

Hi,

I just ran the tasking example on a PentiumPro 200 with Linux and
GNAT 3.07 and got an average execution time of 2.75 sec.

Michael

-- 
------------------------------------------------------------------------
--Dipl.-Ing. Michael Paus   (Member: Team Ada)
--University of Stuttgart, Inst. of Flight Mechanics and Flight Control
--Forststrasse 86, 70176 Stuttgart, Germany
--Phone: (+49) 711-121-1434  FAX: (+49) 711-634856
--Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)

Re: Ada versus Java - Tasking

[Dale Pontius]

In article <1997Jan19.122511.1@eisner>,
        kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>
> Operating system developers have a much better chance to make the
> scheduling interact with the hardware properly, so I think the better
> choices are:
>
>       1) Rely on OS threading support, and wait for improvements.
>
>       2) Lobby the operating system provider for better support,
>          using all methods available, including examples of other
>          operating systems which do it better, either on the same
>          hardware or some other hardware.
>
        3) Adopt another thing from NT, fibers. Leave a thread to
           be defined as something that is scheduled by the kernel,
           but add a structure like NT fibers or user threads, that
           is scheduled in the user space. This doesn't, of course,
           drop pressure on the OS provider for making the very best
           thread switch possible.

Dale Pontius
(NOT speaking for IBM)

Re: Ada versus Java - Tasking

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <5bvt6v$sik@mdnews.btv.ibm.com> pontius@btv.ibm.com (Dale Pontius) writes:

   In article <1997Jan19.122511.1@eisner>,
           kilgallen@eisner.decus.org (Larry Kilgallen) writes:
   >
   > Operating system developers have a much better chance to make the
   > scheduling interact with the hardware properly, so I think the better
   > choices are:
   >
   >       1) Rely on OS threading support, and wait for improvements.
   >
   >       2) Lobby the operating system provider for better support,
   >          using all methods available, including examples of other
   >          operating systems which do it better, either on the same
   >          hardware or some other hardware.
   >
           3) Adopt another thing from NT, fibers. Leave a thread to
              be defined as something that is scheduled by the kernel,
              but add a structure like NT fibers or user threads, that
              is scheduled in the user space. This doesn't, of course,
              drop pressure on the OS provider for making the very best
              thread switch possible.

   Dale Pontius
   (NOT speaking for IBM)

This won't help if the user threads aren't effieciently implemented.
HP-UX has POSIX threads implemented in user space, and they aren't
significantly more lightweight than POSIX threads in the kernel.
Has anyone measured the difference between fibers and threads or
processes in NT?

Re: Ada versus Java - Tasking

[Jon S Anthony]

In article <1997Jan19.122511.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> Operating system developers have a much better chance to make the
> scheduling interact with the hardware properly, so I think the better
> choices are:
> 
> 	1) Rely on OS threading support, and wait for improvements.
> 
> 	2) Lobby the operating system provider for better support,
> 	   using all methods available, including examples of other
> 	   operating systems which do it better, either on the same
> 	   hardware or some other hardware.

Abosolutely.  If you happen to need something better than this you
probably should not be using typical run of the mill OSs in the first
place.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada versus Java - Tasking

[Jim Hopper]

In article <dtaylor-1901971434080001@usr1-d16.iquest.com>
"David Taylor" <dtaylor@iquest.com> writes:

> As I was reading this post, I wondered how these timings would compare with
> a lowly Apple 120MHz 604 running GNAT 3.07 on top of MachTen.  Some numbers
> I got using the same gnatmake above were:
> 
> home/dave/prod> prod_cons
>  4.916670000
> /home/dave/prod> prod_cons
>  5.000000000
> /home/dave/prod> prod_cons
>  5.066664000
> /home/dave/prod> prod_cons
>  4.583350000
> /home/dave/prod> prod_cons
>  4.699972000
> /home/dave/prod> prod_cons
>  4.566644000
> /home/dave/prod>
> 
> Since the processors are comparable, I suspect the most improvement in time
> is because of 3.07.  I no longer have 3.05 installed, so I can't check the
> timing with it.  Anyway, not too shabby.


Dave,

no these times are better because the 604e at the same clock speed is
faster than a pentium pro at the same clock speed (byte magazine
article recently) and much faster than a pentium.  a 603e is roughly
equal to a pentium at same clock speed.

The piwg benchmarks as i recall showed no gain in performace between
3.05 and 3.07 in this area.  (i could be wrong its been several months
since i looked at the numbers).  another interesting thing from the
piwgs (i have the graphs for these) is that my 120 mhz 8500 beats our
150 mhz SGI indy in most all piwg tests, and my 180mhz upgrade to the
same 8500 boosted it to the point where it beats out our 250mhz onyx in
most all tests.

jim

Ada Tasking revisited (was: Re: Ada versus Java - Tasking)

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <32E2E430.50EF@bix.com> Tom Moran <tmoran@bix.com> writes:


   > These task switching times are still pretty horrible though
   Yes, and Win95 takes (on my P60) over 700 microseconds just to call
   Ada.Calendar.Clock
     You can use an Ada compiler that doesn't map tasks to OS threads or,
   for really fast stuff, use DOS (where the OS doesn't get in the way).

Interesting thought. Develop on a workstation, then deploy on DOS for
maximum speed!

I have run a simple test of the effect of using protected types to
reduce task switching. The protected type is introduced as a buffer
between the two tasks, and even with a buffer size of 1 leads to a
significant reduction in time. My code is a somewhat simplified
version of an example which was posted earlier, in that it uses only 2
tasks:

with Interfaces;
with Ada.Calendar;
with Ada.Text_Io;

use Ada;
procedure Q_Prod_Cons is
   procedure Time_This is
-- Note different size of Data_Block
      type Data_Block is array (1 .. 4 ) of Interfaces.Unsigned_8;
      for Data_Block'Component_Size use Interfaces.Unsigned_8'Size;
      for Data_Block'Size use 4 * Interfaces.Unsigned_8'Size;

      protected type Buffer is
         entry Put(X: in Data_Block);
         entry Get(X: out Data_Block);
      private
         Data: Data_Block;
         Full: Boolean := False;
      end Buffer;

      protected body Buffer is
         entry Put(X: in Data_Block) when not Full is
         begin
            Data := X; Full := True;
         end Put;

         entry Get(X: out Data_Block) when Full is
         begin
            x:= Data; Full := False;
         end Get;
      end Buffer;
      type Buffer_Ptr is access all Buffer;

      task type Consumer_Agent (Q : access Buffer);

      task body Consumer_Agent is
         Local : Data_Block;
      begin -- Consumer_Agent
         for I in 1..100000 loop
            Q.Get(Local);
         end loop ;
      end Consumer_Agent;
      type Consumer_Ptr is access all Consumer_Agent;
      
      
      task type Producer_Agent (Q : access Buffer);

      task body Producer_Agent is
         Data : Data_Block := (others => 0);
      begin -- Producer_Agent
         for I in 1..100000 loop
            Q.Put(Data);
         end loop ;
      end Producer_Agent;
      type Producer_Ptr is access all Producer_Agent;
      
      Buf: Buffer_Ptr;
      Consumer : Consumer_Ptr;
      Producer : Producer_Ptr;
      
   begin -- Time_This
      Buf := new Buffer;
      Consumer := new Consumer_Agent(Q => Buf);
      Producer := new Producer_Agent (Q => Buf);
   end Time_This;
   
   Stop  : Calendar.Time;
   Start : Calendar.Time := Calendar.Clock;
   
   use type Calendar.Time;
begin -- Prod_Cons
   Time_This;
   Stop := Calendar.Clock;
   Text_Io.Put_Line (Duration'Image (Stop - Start) );
end Q_Prod_Cons;

The original version, modified to use only 2 tasks, and with 100000
iterations use ca. 23 seconds on my machine, while the above version
uses only 15 seconds on average. This is because a thread may execute
operations on behalf of another thread while it is executing inside
the protected type. 

With a longer queue, the effect would be even greater, of course.

Ole-Hj. Kristensen

Re: Ada versus Java - Tasking

[jim hopper]

> > on my 180mhz powermac 8500 i get (with gnat 3.07) using -O2 [compiling
> > with -03 and -gnatp shave about .3 seconds off this time] now if i can
> > just get the mac tasking to use the new multiprocessor api so i can use
> > that second 180mhz processor un my 8500 ;-)
> 
> Is that API different from the Thread Manager ?
> 


Larry,

well the answer is yes and no ;-)  current threads are on top of one apple
thread.  kind of a lightweight lightweight thread :-)

One of my goals is to change the posix thread library we use for mac
tasking (both unix and MacOS apps) to use the Apple/Daystar multiprocessor
api threads.  if i can make that working it would let my multiprocessor
mac be used from ada, but would also give us full preemtive tasks (even on
a single processor) for mac os standalone apps.

jim

Re: Ada versus Java - Tasking

[Dr. John B. Matthews]

In article <dtaylor-1901971434080001@usr1-d16.iquest.com>, "David Taylor" <dtaylor@iquest.com> writes:

[Using Jeff Carter's <carter@innocon.com> simple yet compelling
example with MachTen and gnat 3.07, Dave gets a shade under 5
seconds per run.]

Using gnat 3.07 with the same options on a 120 MHz PowerPC 604, I
got an average execution time of 4.05 seconds. On a 180 MHz PowerPC
604e, Jim Hopper reports an average execution time of 2.32 seconds.

Both our results are less variable than Dave's, probably because
we're using Tenon's CodeBuilder product. The latter doesn't include
MachTen's inet stuff, so it's may have less overhead.
 
"Since the processors are comparable, I suspect the most improvement
in time is because of 3.07.  I no longer have 3.05 installed, so I
can't check the timing with it."

The clock speeds are comparable, but the 604 and 604e are more on
par with the P6. Like you I don't have 3.05 handy, but my other
tasking code didn't improve at all with 3.07; there's more to it
than that.

"Anyway, not too shabby."

Indeed!

John
----------------------------------------------------------------
John B. Matthews, M.D.
jmatthews@nova.wright.edu; john_matthews@ccmail.dayton.saic.com
"Whom the gods would destroy, they first invite to program in C"

Re: Ada versus Java - Tasking

[Larry Kilgallen]

In article <5c12ah$cq3@server1.erinet.com>, jhopper@erinet.com (Jim Hopper) writes:

> on my 180mhz powermac 8500 i get (with gnat 3.07) using -O2 [compiling
> with -03 and -gnatp shave about .3 seconds off this time] now if i can
> just get the mac tasking to use the new multiprocessor api so i can use
> that second 180mhz processor un my 8500 ;-)

Is that API different from the Thread Manager ?

Larry Kilgallen

Re: Ada versus Java - Tasking

[Jim Hopper]

In article <5bvtek$2b06@info4.rus.uni-stuttgart.de>
michael@ifr.luftfahrt.uni-stuttgart.de (Michael Paus) writes:

> Hi,
> 
> I just ran the tasking example on a PentiumPro 200 with Linux and
> GNAT 3.07 and got an average execution time of 2.75 sec.
> 
> Michael
> 
> -- 
> ------------------------------------------------------------------------
> --Dipl.-Ing. Michael Paus   (Member: Team Ada)




on my 180mhz powermac 8500 i get (with gnat 3.07) using -O2 [compiling
with -03 and -gnatp shave about .3 seconds off this time] now if i can
just get the mac tasking to use the new multiprocessor api so i can use
that second 180mhz processor un my 8500 ;-)

hopper@CodeBuilder% prod_cons
 2.316654000
hopper@CodeBuilder% prod_cons
 2.316654000
hopper@CodeBuilder% prod_cons
 2.316694000
hopper@CodeBuilder% prod_cons
 2.300028000
hopper@CodeBuilder% prod_cons
 2.316654000

jim

Re: Ada versus Java - Tasking

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <JSA.97Jan20164909@alexandria> jsa@alexandria (Jon S Anthony) writes:

   In article <1997Jan19.122511.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

   > Operating system developers have a much better chance to make the
   > scheduling interact with the hardware properly, so I think the better
   > choices are:
   > 
   > 	1) Rely on OS threading support, and wait for improvements.
   > 
   > 	2) Lobby the operating system provider for better support,
   > 	   using all methods available, including examples of other
   > 	   operating systems which do it better, either on the same
   > 	   hardware or some other hardware.

   Abosolutely.  If you happen to need something better than this you
   probably should not be using typical run of the mill OSs in the first
   place.

   /Jon
   -- 
   Jon Anthony
   Organon Motives, Inc.
   Belmont, MA 02178
   617.484.3383
   jsa@organon.com

Many applications are typically required to both run on standard OSs,
have good performance, and be portable. DB and TP systems are obvious
examples. Of course, you can just avoid using any mechanisms which are too
slow, but that may rule out using mecanisms which otherwise could be
used to great advantage. With transaction response times in the range
of typically 1..10 milliseconds, you don't have time for too many
context switches, although I do not think using Ada tasks to represent
transactions would be prohibitively costly. The greatest resource hog
in the system I'm working on (written in C++, btw) is undoubtedly the
network layer, which accounts for more than 1/3 of the CPU time...

Re: Ada versus Java - Tasking

[Jeff Carter]

David Taylor wrote:
...
> 
> As I was reading this post, I wondered how these timings would compare with
> a lowly Apple 120MHz 604 running GNAT 3.07 on top of MachTen.  Some numbers
> I got using the same gnatmake above were:
> 
> home/dave/prod> prod_cons
>  4.916670000
> /home/dave/prod> prod_cons
>  5.000000000
> /home/dave/prod> prod_cons
>  5.066664000
> /home/dave/prod> prod_cons
>  4.583350000
> /home/dave/prod> prod_cons
>  4.699972000
> /home/dave/prod> prod_cons
>  4.566644000
> /home/dave/prod>
> 
> Since the processors are comparable, I suspect the most improvement in time
> is because of 3.07.  I no longer have 3.05 installed, so I can't check the
> timing with it.  Anyway, not too shabby.
> 
> Dave

GNAT 3.07 for DOS on the same machine (as the 18-second results) gives
results in the 5.5 .. 5.8 second range for a more complicated problem.
GNAT 3.04a for Win95 was about 29 seconds for this problem on this
machine. Could it be that 3.07 does tasking better than 3.04a?
-- 
Jeff Carter
Innovative Concepts, Inc.

Re: Ada versus Java - Tasking

[Robert Dewar]

Jonas asks

">My test starts 50 producer-consumer pairs that run in
>parallell. Each pair produces/consumes 1000 messages
>of 50 bytes. I get the following timing on my P133,
>16M, and running Win95:
>
>Ada  (Gnat 3.04a)  : ~30 s
>Java (MS SDK-Java) : ~15 s
>
>This result was very much to my surprise!
"


This should not surprise you. The timing of such a program (assuming both
are using kernel threads) is almost completely dependent on the number of
kernel calls issued. It may well be for example that some non-obvious
aspect of the way you wrote the program in the two languages leads to
such a difference (Ada taskings semantics are quite a bit more developed
than those in Java, and this may show up as extra kernel calls in some
cases, e.g. the avoidance of priority inversion in Ada may cost extra
(but be wll worth it!)).
\