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,ccd04b355056eb04 X-Google-Attributes: gid103376,public From: James E. Hopper Subject: Re: performance tuning with gnat Date: 1996/05/10 Message-ID: <4n069g$rrf@eri1.erinet.com>#1/1 X-Deja-AN: 154170879 distribution: world references: <4mvkq1$nr4@cville-srv.wam.umd.edu> content-type: text/plain; charset=ISO-8859-1 x-xxmessage-id: organization: Personal mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-05-10T00:00:00+00:00 List-Id: In article <4mvkq1$nr4@cville-srv.wam.umd.edu> Eric Anthony Spear, spear@wam.umd.edu writes: >Hi! I'm running gnat 3.01. I have a program that runs slower than I'd >like. The trouble is, I don't know which parts are causing the >slowdown. Are there any tools that can help me profile my program, >breaking down by procedure/function cpu usage and/or disk usage/wait >times? > I can offer a few guesses and places to look for slowdowns. We developed our Digital Radar Landmass Simulation (DRLMS) using gnat on an SGI but i think most of this applys to all gnats 1. Exceptions are really slow. By that i mean even having an exception handler slows things way down. we ended up at the end stripping out most of our exception handlers 2. Unconstrained Arrays are REAL slow compared to constrained arrays and compared to the Vads compiler we were using on our first generation product. in some cases they were as much as 5 times slower than the same code compiled with VADS. Most of our arrays were bitmaps and we ended up using constrained arrays and using a bounds rect to specify which part of the array held valid data. with this we ran slightly faster than the VADS implementation. in addition since we were doing convolutions of large bitmaps in realtime (30 hz) we had to suppress checks in critical sections. these were the critical time elements we discovered. there is lots of machine specific stuff that SGI's toolset made easier to find using their profiler and pixie utilities but you didnt specify platform and i didnt do most of this work so i am the wrong person to talk about it (the correct person is doing final integration of the radar into an F-111 flight trainer in austrailia now). Final word is we ended up processing 4 times the number of pixels at a faster frame rate 30 vs 25 hz in about 2.5 times the processors on an Onyx (no pipe required) from our first generation product using vads. yes a LOT of this comes from improved algorithms but we were VERY pleased overall with compiler performance. [which reminds me of a kind of funny story. we wrote the original marketing demos of our SAR radar sim to run on a mac. we were showing it at ITSEC on a mac powerbook and a man from a spanish firm was looking at it. when i asked him if he wanted to hear about it he told me no he needed it to run real time. Since the powerbook demo was already running at 2-3 times FASTER than realtime i replied "no problem i will be happy to slow it down for you!" ] ;-) In any case gnat on the sgi impressed our team as well as the customers engineers. they were a VADS house but they are switching as fast as they can to gnat after seeing how responsive ACT and SGI were. As well as how easy it was to go from version to version during the sgi beta period. best jim Jim Hopper Chief Technical Advisor Systems and Software Technology Division Science Applications International Corp. I speak only for myself by the way!