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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,70d59e24bec599dc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-24 08:22:57 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!novia!howland.erols.net!newsfeed.dacom.co.kr!intgwlon.nntp.telstra.net!nsw.nnrp.telstra.net!not-for-mail Message-ID: <3B36CB45.137D30C5@mullum.com.au> From: Rod Kay X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Profiling Gnat re. pthread_malloc, pthread_getspecific, system finalisation & tasking. References: <5F6Z6.118864$%i7.83650084@news1.rdc1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 25 Jun 2001 01:25:25 -0400 NNTP-Posting-Host: 203.109.169.46 X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 993396167 203.109.169.46 (Mon, 25 Jun 2001 01:22:47 EST) NNTP-Posting-Date: Mon, 25 Jun 2001 01:22:47 EST Organization: Customer of Telstra Big Pond Direct Xref: archiver1.google.com comp.lang.ada:9071 Date: 2001-06-25T01:25:25-04:00 List-Id: tmoran@acm.org wrote: > > > > (Mandrake 8.0) machine. I've used inlining, O3 optimisation, and > > > disabled all run-time > > > > By "using inlining" do you mean pragma Inline? Did you also specify -gnatn? I'm using Gnat's pragma Inline_Always, which I believe operates regardless of the -gnatn switch. (I had trouble linking when I tried pragma Inline & -gnatn.) > A 10x difference in speed is unlikely to be caused by, or solved by, > any of those things. Yes, as it turns out the problem was unrelated to the optimisation controls. A critical function dereferenced a forward reference type (from John G. Volan's forward reference package), resulting in an instance of one of my types being created and used, in place of the instance actually referred to. This type contained a Container from the Booch Components, which is a controlled type. The creation/destruction overhead, incurred each time the procedure was called, essentially crippled the program. As it turns out the forward reference was unnecessary, a relic from an earlier circular elaboration problem, and performance improved markedly when it was removed. > > > Somehow your Ada code does not correspond to your C++ code, regarding > > threads. > Likely. Though there may also be an optimization opportunity in > making it *less* like the C. I'm thinking in particular of getting > rid of malloc's by using local (stack) declarations instead. Ada > programs typically use heap allocation a lot less. I've found that the AWS comms packages I'm using (in an unrelated area of the application), makes use of Ada's tasking. The AWS packages are not used in the processing which I'm profiling, but their presence seem to impose a tasking overhead on all subprograms. When I removed the AWS packages from the program, the pthread_* and system__tasking__* subprograms vanished from the profile results. The program is now performing only a little below the c++ version, and with a little more optimisation, I'm hoping to equal or exceed that. Thanks to all for your time and advise. regards, Charles.