Re: The GNU Ada compiler

[Craig Carey <research@ijs.co.nz>]

On Wed, 21 Dec 2005 16:07:57 +0100, Ludovic Brenta wrote:
>"Steve Whalen" <SteveWhalen001@hotmail.com> wrote:
>> In particular for proselytizing Ada, stable GMGPL Ada compilers need
>> to be available for Windows (Ming and cygwin), Redhat, SUSE,
>> Mandrake, and Solaris.
>
>I agree wholeheartedly.  For Windows, there are already two binary
>distributions of GNAT under GMGPL: AIDE[1], and MinGW[2].  I have
>tried neither of them
...


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.

When I compile 53 Ada files then I get these timing results:

  (1) GNAT 3.15p for NT :  1min42sec, 1m34s. The average = 98 secs.
   The output file "tp-model2.o" is of size 1.12 MB.

  (2) The new AdaCore GNAT GPL 2005 compiler: 14 minutes 10 seconds
   (=850 secs)
   The output file "tp-model2.o" is of size 1.55 MB, which is 38.55%
   larger.

So the new AdaCore compiler was measured to be 8.67 times slower.

Evidently the GPL 'unusable' gets extremely slow on large files.

My big files in the test are automatically generated by a modified
AdaGOOP system (which allows free-form recurse parsing of the
syntax tree instead of having a case statement inside of a loop).

AdaGOOP:
   http://www.martincarlisle.com/ada_stuff.html
   http://tope.tigris.org/

Probably the AdaCore Ada compiler can't actually compile its own source
code, when run in Windows. I justify that by noting that my
tp-model2.adb file (the largest in the test) is 133kb big and 4136
lines, and GNAT has about 32 *.adb files that having sizes from 136 kb
to 538 kb, with a median being about 205 kb.

The GPL compiler is expected to be worse if the optimization
level was changed from -O0 to -O2. I noted that MinGW GNAT spent much
more time optimizing than compiling on large files , and it seems that
the size goes up 38% (but I didn't discover if the FSF programmers
had made their optimizer faster instead of slower).

Another way that might validly get the GPL compiler to produce a
slower result, could be to take advantage of the new "limited with"
feature. However perhaps the code for GNAT 3.15 is using child packages
(and conversions on pointers), which is seemingly similar and slow.

Ther GCC programmers really don't seem to want to make AdaCore's
commercial Ada compilers to go faster. I doubt they actually know why
the compiler is running slowly; it is more about groups of opposing
issues (tradeoffs, rather than the 'always do timing tests' advocacy
that GPL opposing FreeBSD programmers familiarize themselves with).


>[1] http://stephane.rochebrune.org/aide/aide.html
>[2] http://www.mingw.org
>[3] http://www.blastwave.org
>[4] http://www.canoedissent.org.uk/ss/type.jsp?c=prog
>[5] http://www.freebsd.org
...

>FreeBSD[5] seems not to be very active WRT Ada, but there are ports
>for gnat 3.15p, asis and glade.  The ports for GCC 3.4.4, 4.0.3, 4.1.0
>and 4.2.0 (the latter three being works in progress) lack Ada support.
>I am quite confident that FreeBSD's GCC maintainer would gratefully
>accept patches to enable Ada on that platform.

FreeBSD has had dead Ada ports and ideally that port would be deleted
if it does not run. The FreeBSD Gvd port got deleted recently.

Years ago Mr Tardieu (in France) privately said he was using a native
FreeBSD compiler and I guess he used select statements for IO otherwise
tasks don't run. Alternatively the FreeBSD Ada port has been debugged,
and it might involve few changes.

However FreeBSD is probably a serious alternative to Linux once the
Linux Ada compiler is run under the emulator:
http://ijs.co.nz/code/ada95-freebsd-gnat-under-linuxulator.htm

--

A Russian ftp filesearching engine (named at the metasearch site,
http://www.astalavista.com/), found these ftp sites that hold
copies of the 2002 GNAT 3.15p compiler:

** ftp://ftp.dit.upm.es/mirrors/cs.nyu.edu/pub/gnat/3.15p/winnt/
** ftp://ftp.laas.fr/pub/tsf/agnan/Installeposte/

I was reading the GCC mailing list and I guess the community of
GCC developers don't know why the compiler is slow, and are quite
competent at talking about unavoidable difficult trade-offs while
not knowing where the bugs are. At one time they tried to blame
the boehm garbage collector. Sending up huge CVS patches and
resolving to never back out, marked on quantum deterioration.

Mr Dewar hopefully noted that the colourizing algorithms for
optimizing register use was a strict/hopeful/etc need that had a
capability of possibly justifying a slower compiler. Perhaps the
original text was too brief.




Craig Carey