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: Edmond Walsh Subject: Re: Tasking performance between Ada83 and Ada95 Date: 1997/06/15 Message-ID: #1/1 X-Deja-AN: 248543543 Distribution: world X-NNTP-Posting-Host: walsh.demon.co.uk [158.152.134.205] References: <1997Jun6.115223.7384@relay.nswc.navy.mil> <7h6UFCAdNsmzEwg3@walsh.demon.co.uk> Organization: edmond Newsgroups: comp.lang.ada Date: 1997-06-15T00:00:00+00:00 List-Id: In article , Robert Dewar writes >Edmond Walsh said > ><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