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: bobduff@world.std.com (Robert A Duff) Subject: Re: Tasking performance between Ada83 and Ada95 Date: 1997/06/07 Message-ID: #1/1 X-Deja-AN: 246924838 References: <1997Jun6.115223.7384@relay.nswc.navy.mil> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-06-07T00:00:00+00:00 List-Id: In article <1997Jun6.115223.7384@relay.nswc.navy.mil>, Mike Rose wrote: >In comparing the results between the two compilers, I found that the tasking >performance is much slower with GNAT than with Alsys, every test was at least >10 times slower and some were much more. > >Our software depends heavily on tasking. Is there any way to improve the >tasking performance with GNAT ? Probably the problem is that GNAT uses the tasking (threads) of the underlying OS, and what you're measuring is the poor performance of those underlying systems. Often, the issue is that you're doing system calls to lock things and so forth -- and system calls take a l-o-o-o-n-g time. I don't think it's all that hard to make it fast -- change the RTS to do all its own task dispatching and whatnot, and never never do a system call in time-critical operations. But then you lose something: you have to jump through hoops to do asynchronous I/O, for example. Also, the O/S doesn't know about your tasks, so it won't know how to schedule your tasks in relation to tasks (threads) in other unrelated programs. If a page fault happens, and you're not using OS threads, your whole program will wait for disk I/O. A real-time program might not care about these things, however. - Bob