Re: Tasking performance between Ada83 and Ada95

[Edmond Walsh <edmond@walsh.demon.co.uk>]

In article <dewar.865870961@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
writes
>Edmond Walsh said
>
><<We had a similar problem when moving some Ada 83 code running on a
>Harris NightHawk to Ada 95 (Gnat) on an SG.  It took a lot of effort to
>get the code running reasonably on the SG.  The underlying problem was
>the mapping of the Ada Tasks to Unix threads.  The Harris (now
>Concurrent) system was very good, reflecting the Real Time background of
>Harris. (I was not involved in the porting, I was just an interested
>observer.)>>
>
>Of course, the mapping of Ada tasks to Unix threads is certainly a *good
>thing* if you need to take advantage of the flexibility of this mapping.
>For example, if you are using one of SGI's high end MP's, then you 
>definitely want this mapping. But there certainly is an efficiency
>penalty to be paid. 
>
>Actualy from your post it is not quite clear what exactly you are referring
>to in "lot of effort" and "underlying problem" here. Were there problems
>other than efficiency? Sometimes, especially in Ada 83 programs, where the
>dispatching semantics were not defined, programs make assumptions about the
>dispatching that are non-portable. This is avoided in Ada 95 if you are using
>a compiler that implements full Annex D semantics (true of the SGI compiler
>for example), but that does not necessarily help the porting of legacy code.
>
>Robert dewar
>Ada Core Technologies
>
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.  
-- 
Edmond Walsh