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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!goblin1!goblin3!goblin.stu.neva.ru!exi-transit.telstra.net!pit-spool.telstra.net!pit-in1.telstra.net!news.telstra.net!news-south.connect.com.au!not-for-mail From: Greg Bek Newsgroups: comp.lang.ada Subject: Re: Mixing Ada and c Date: Wed, 30 Sep 2009 11:30:35 +0930 Organization: Customer of AAPT Pty Ltd Message-ID: References: NNTP-Posting-Host: c-61-68-224-218.ade.connect.net.au Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news-01.bur.connect.com.au 1254276037 2660 61.68.224.218 (30 Sep 2009 02:00:37 GMT) X-Complaints-To: abuse@connect.com.au NNTP-Posting-Date: Wed, 30 Sep 2009 02:00:37 +0000 (UTC) User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:8534 Date: 2009-09-30T11:30:35+09:30 List-Id: Maciej Sobczak wrote: > On 25 Wrz, 18:19, Mike wrote: > >> I have a c main program which does socket communications and calls and >> ada program which generates the data to be sent over the wire. What >> I've noticed is that the ada portion of the program runs almost twice >> as slow when linked with the c main than when run in stand alone with >> an ada driver. Is there a general reason that ada code in general runs >> more slowly when linked with and called by a c program? > > I have no idea whether this is relevant, but you might want to check > whether the C thread (the one calling Ada) was registered at the Ada > runtime. If not, then some of the operations might be trying to use > the information that is not available and then failing over to > alternative strategies. > Again, I have no idea if this is the case, but I can easily imagine > the slowdown caused this way. > I am also interested in the actual reasons for what you see. > > -- > Maciej Sobczak * www.msobczak.com * www.inspirel.com > > Database Access Library for Ada: www.inspirel.com/soci-ada When an Ada subprogram is called there is usually a significant amount of context needed for the subprogram to operate correctly: eg: Stack Limit Exception Tables Memory Pools Floating Point Unit configuration If you use an Ada main program, then a subprogram can safely assume that all this context has been established correctly. But as soon as you put a pragma Export on the subprogram, then the Ada compiler has to assume that it could be called from any where, and that no assumptions about context can be made. So usually you will suffer a performance penalty as the subprogram establishes an Ada context. For example, on a processor with a reasonable register set (ie: not Intel), the stack limit may be stored in a fixed register location, making stack limit checks very quick in a pure Ada context, however if called from C, then the compiler will have to generate code to load the stack limit from a known memory address somewhere in the Ada runtime. You can use pragma Suppress creatively to speed up some code, but as always your mileage will vary. Greg