From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a5681531ca1cf09e
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Tasking performance between Ada83 and Ada95
Date: 1997/06/15
Message-ID: <dewar.866376446@merv>#1/1
X-Deja-AN: 248588553
References: <1997Jun6.115223.7384@relay.nswc.navy.mil> <dewar.865693453@merv>
  <7h6UFCAdNsmzEwg3@walsh.demon.co.uk> <dewar.865870961@merv>
 <Db0ccBASt4ozEwUo@walsh.demon.co.uk>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-06-15T00:00:00+00:00
List-Id: <comp.lang.ada>


Edmond Walsh said

<<Efficiency was a significant problem.  The program ran correctly in Ada
95 on the SG Indy with each task being executed as a seperate unix
process.  However this ran rather slowly because of the large overheads
in context switching unix processes.  In the original Nighthawk '83
version the two main components (consisting of many tasks) each ran as a
seperate unix process and the individual tasks in the components were
controlled by the Ada run time executive.  The blocking of one task due
to inter (unix) process comunications did not block the entire
component.  When this scheme was ported to the SG Indy it was found that
the blocking of a task due to inter (unix) process communications did
block the entire component.  Working around this problem to achieve
reasonable run time and correct operation was what caused the trouble.  
>>


You mean separate unix thread, rather than separate unix process I think.
At least there is certainly no need to use separate processes for each
task. Nevertheless that can indeed introduce extra overhead.

In the Ada 83 world on monoprocessors, the use of a special Ada exec for
task switching on top of an OS often made sense, and this is exactly what
we get when we port the FSU threads. The advantage of the FSU threads is
high efficiency and exact semantic accuracy.

However, these days, more and more work is done on multi-processors, and
then of course you have no choice if you want to distribute tasks across
processors other than to use the system level threads. Furthermore, the
efficiency hit from operating these threads on separate processors may
indeed be significant.

No obvious solution here ... that's why the best approach seems to be to
provide a choice of threads libraries on machines where it makes sense.
In version 3.10 of GNAT, we we providing that choice for Solaris and
for Linux. We may do it for additional ports as we go along. So far we
did not port FSU threads to SGI (one of the motives for doing so, accuracy,
does not apply, since the SGI threads implementation is exactly correct
for Ada, one of the advantages of having the vendor have an interest and
stake in Ada!) But the efficiency issue might still apply.

Note that on the SGI implementation of GNAT, there are controls ovre how
tasks are distributed among processes, and it is worth while tuning these
right, especially when using a multi-processor machine