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-Thread: 103376,f16a645029bb2cdd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!203.109.252.33.MISMATCH!newsfeeds.ihug.co.nz!lust.ihug.co.nz!ihug.co.nz!not-for-mail From: Craig Carey Newsgroups: comp.lang.ada Subject: Re: The GNU Ada compiler Date: Sat, 31 Dec 2005 14:36:49 +1300 Organization: Ihug Ltd Message-ID: References: <1500332.U7CjsdsL0l@linux1.krischik.com> <1691618.MhViCBI7GN@linux1.krischik.com> <8950475.JSDDGHQjBG@linux1.krischik.com> <1135119585.533549.119130@g49g2000cwa.googlegroups.com> <87bqzaqyia.fsf@ludovic-brenta.org> <43b189e5$0$26923$9b4e6d93@newsread4.arcor-online.net> NNTP-Posting-Host: 203-173-179-191.bliink.ihug.co.nz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: lust.ihug.co.nz 1135992994 31460 203.173.179.191 (31 Dec 2005 01:36:34 GMT) X-Complaints-To: abuse@ihug.co.nz NNTP-Posting-Date: Sat, 31 Dec 2005 01:36:34 +0000 (UTC) X-Newsreader: Forte Agent 3.1/32.783 Xref: g2news1.google.com comp.lang.ada:2401 Date: 2005-12-31T14:36:49+13:00 List-Id: On Tue, 27 Dec 2005 19:37:24 +0100, Georg Bauhaus wrote: >Craig Carey wrote: >> The GNAT GPL compiler of http://libre.adacore.com/ >> gnat-gpl-2005-pentium-mingw32msv-bin.exe.zip (libre.act-europe.fr), >> >> is curiously slow:about 9 times slower, or worse. > >I get ratios 8/14 and 8/30 on the average when comparing 3.15p with 3.4.5 >(GNAT GPL 2005) and 3.15p with a 4.1 FSF GNAT from August this year, >compiling a recursive descent parser. Rewriting that leads to: (1) FSF GCC 4.1 is 3.75 slower (=30/8) than GNAT 3.15p; (2) AdaCore GPL GNAT 2005 is 1.75 times slower (14/8) than GNAT 3.15p. If not in Windows then please say so. >Part of the speed difference is probably due to --enable-checking >in non-release compilers (the 4.1 case). That enables assert statemnts and maybe the effect is not over 10%. A possible legal consequence of the actions of AdaCore is that corporations may delete the AdaCore GPL (GNU Public licence) and throw it away. In some countries a High Court prosecution of a copyright violator may only seek a compensation equal to the harm. Unless the law in New Zealand was changed, then such is the law here. Becuase corporate end users would be better off using the old GNAT 3.15p compiler, and it was free, and the standard of the compilers got too low and might be getting worse, then companies could use the newest compilers and jettison the licences. If AdaCore could argue that the profits of those end-users (that (lawfully) violate its GPL) are too high compared to its own, then a court could be skeptical. For example, there is a large amount of evidence at gcc help showing that the leader of Ada preferred to avoid the outcome more than he preferred to accept it. The FSF seems to have 2 laywers on its board of directors: http://www.fsf.org/about/leadership.html >Have you compared execution speeds of the executables produced? I suppose I could compare the sizes under the theory that everything is much worse in Windows but GNAT 4 is unlikely to build in Windows. Maybe GNAT for Windows XP could be cross compiled on an OC Systems OS/390. I only tested 53 files in my last test, since the AdaCore compiler crashed. The version 3 Windows compiler and very likely, version 4 too, is going to be unusable. A A test could be done where a single *.adb file is increasingly lengthened by adding procedures that are not nested but that call each other. It seems that the size of the object file and the compile times, rise too steeply. A problem is that the C++-ishy GCC backend is a slave getting repeatedly called and so it lacks an ability to cause the probably hyper-linear blowout speeds in the size of the *.o object files (and also compile times) that is suspected. I could retest as Mr Obry said, but the compiler is on the way out. However I quite agree with Mr Obry that the formality of producing the figures needing to show that, is proper. Alternatively the USAFA's Mr Carlisle (and the DoD owning over 120 millions lines of Ada code) could be told to cut up those really *big* files (110 KB or more). Craig