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: Daniel Thonon Subject: Re: Gnat on OpenVMS Date: 1999/05/21 Message-ID: <3744EFE6.79F99405@wanadoo.fr>#1/1 X-Deja-AN: 480408335 Content-Transfer-Encoding: 7bit References: <7hshfq$5tc$1@front1.grolier.fr> <37424625.4A33DD44@wanadoo.fr> <7hv83e$t2o$1@front4.grolier.fr> <7i19la$2ci$1@nnrp1.deja.com> X-Accept-Language: fr Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@wanadoo.fr X-Trace: wanadoo.fr 927264750 11762 164.138.184.154 (21 May 1999 05:32:30 GMT) Organization: Wanadoo, l'internet avec France Telecom Mime-Version: 1.0 NNTP-Posting-Date: 21 May 1999 05:32:30 GMT Newsgroups: comp.lang.ada Date: 1999-05-21T05:32:30+00:00 List-Id: Robert Dewar wrote: > In article <7hv83e$t2o$1@front4.grolier.fr>, > "Thierry Lelegard" wrote: > > 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. > > From this description it is clear that you are looking > at unoptimized GNAT code rather than optimized code. Indeed > it is the case that -O0 in gcc produces very inefficient > code. When you tell gcc not to optimize your code, it really > believes you, and does not do even the most elementary > optimizations. In addition there is no scheduling at all > in this mode. I also looked at the code generated by gnat on Digital UNIX (with different -O levels and chip dependant optimizations) and found the same kind of problem. For example, just by counting the number of statements in a loop, I found a ratio of more than 2 between gnat and DECAda. The GEM code was quite simple to understand, but the gnat code was very complicated, with several unnecessary jumps, for example. > > What we have found in practice is that GNAT execution > efficiency is overall comparable to DEC ADa 83. For some > cases of pure computation, GNAT is significantly faster. > For some tasking and I/O cases, GNAT is slower (the range > we have seen is 2-1 in either direction, but that is at > the extreme, most cases are much closer to comparable). We did not find the same conclusion, either on simple benchmarks or with our complete application. In some case, gnat is faster, but overall it is really slower. We allready spoke with ACTE about that, but without concluding. -- Daniel THONON (mailto:Daniel.Thonon@grenoble.sema.fr) Sema Group (http://www.semagroup.com) Division Energie et Industrie 36, chemin du Vieux Chene BP 104 - 38243 MEYLAN Cedex - FRANCE Tel : (+33) 4 76 41 46 68 Fax : (+33) 4 76 90 08 63