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,31b8879c52cdbc65 X-Google-Attributes: gid103376,public From: "Thierry Lelegard" Subject: Re: Gnat on OpenVMS Date: 1999/05/19 Message-ID: <7hv83e$t2o$1@front4.grolier.fr>#1/1 X-Deja-AN: 479764072 Content-Transfer-Encoding: 7bit References: <7hshfq$5tc$1@front1.grolier.fr> <37424625.4A33DD44@wanadoo.fr> Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Trace: front4.grolier.fr 927146926 29784 195.36.170.213 (19 May 1999 20:48:46 GMT) Organization: Club-Internet (France) Mime-Version: 1.0 NNTP-Posting-Date: 19 May 1999 20:48:46 GMT Newsgroups: comp.lang.ada Date: 1999-05-19T20:48:46+00:00 List-Id: > We also ported our application from OpenVMS+DECAda to Digital UNIX + > DECAda to Digital UNIX + gnat. We found that the performance was > degraded by a factor of 2 or 3 between DECAda and gnat. Have you sen > anything of the sort with your port ? Yes, roughly. However, I must admit that our tests are not completed yet. Before testing the speed, we must get a functional application, which we did not achieve yet... Among nine large applications, only one works with gnat at the present time. The source code is the same at the working code with DEC Ada (with Ada 83/95 incompatibilites fixed, at least those that the compiler can see, maybe not all subtle behavior differences). You observed a performance degradation by a factor of 2 or 3. I suppose that this can be easily explained: the size of the code is larger by the same factor. For instance, we observed the following sizes: - EXE generated with DEC Ada, no debug info: 9,000 blocks - EXE generated with GNAT, no debug info: 19,000 blocks - EXE generated with GNAT, with debug info: 32,000 blocks I was forced to look at the generated code because some programs experienced strange Program_Error (not elab pb) and GDB failed when we tried to debug it. So, since I was crazy enough in the past to work with Alpha assembler, I decided to find the pb by reading the .S file. The code is uncredibly unefficient, even with /optim=all: no visible instruction rescheduling (critical issue on Alpha), "strange" usage of registers and memory, redundant branches, etc. I have often looked at GEM-generated code in the past, optimized gnat code looks like non-optimized gem code. Anyway, all of these issues may be improved in the future, although the effort to improve the efficiency of a code generator is huge. Our immediate concern is to get a working environment (I mean compiler/debugger, not the applications) and ACT is currently working on this (we already got a new version of the compiler, so they really work on it!). Daniel, did you use GDB on OpenVMS? Did you run into specific problems? I am not in love with the OpenVMS debugger, I just appreciate its functionalities. If GDB can achieve the same features, even with a different user interface (I don't care), I will be delighted to use it. Note: please answer to lelegard@canal-plus.fr, not the "reply-to" address of this note. ________________________________________________________ Thierry Lelegard, Paris, France E-mail: lelegard@club-internet.fr