Re: GNAT's stack checking in Ubuntu 9.04 (and Shootout regex-dna)

[jonathan <johnscpg@googlemail.com>]

On Aug 11, 1:27 am, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
>
> Another way of using modified copies of GNAT library
> units seems to be to use -a ; GNAT then considers
> the library unit in my source directory.  (There is
> probably some risk when the options change from those
> used for compiling the library, though.)


Thanks, -a is right way to go here.  Final report  (for now):


The following remarks apply to single-core runs using
the GNAT 4.3.2 that comes with Debian Lenny (based
on gcc 4.3.2). I've been saying that GNAT 4.3.2 produces
less well optimized executables, but I was not quite
right in this case as I explain below.

Step 1.  Compile without the -a switch:

  -O3 -gnatnp -funroll-all-loops -march=native regexdna.adb

  Running time of ./regexdna: 63 seconds.

  Comment: compilation near instanteous; I suppose it is
  linking to precompiled  Gnat.Spitbol.Pattern  packages.

Step 2.  Compile with the -a switch:

  -O3 -a -gnatnp -funroll-all-loops -march=native regexdna.adb

  Running time of ./regexdna: 51 seconds.

  Comment: Compilation is slow. Looks like it is recompiling
  the  Gnat.Spitbol.Pattern  packages.

  So it looks like the performance problem I was complaining
  about was due to the suboptimal precompiled Spitbol.Pattern.
  In fact it was almost *entirely* due to the sub-optimal
  Spitbol.Pattern, because running time is now close
  to the running time I get from the GNAT GPL compilation.
  (The GNAT GPL I downloaded was for 64-bit machines. I
  would speculate that the precompiled Spitbol.Pattern
  used by the Debian Lenny GNAT was for more general
  architectures.)

Step 3. Copy source code of the spec of   Gnat.Spitbol.Pattern
        into working directory. (I found the source directory by
        using the -gnatu switch during compilation.) You don't
        need to change its name (g-spipat.ads).
        Then edit the  g-spipat.ads  in working directory and
        change Stack_Size from 2000 to (say) 37.

  cp /usr/lib/gcc/x86_64-linux-gnu/4.3.2/adainclude/g-spipat.ads g-
spipat.ads

  Compile with the -a switch:

  -O3 -a -gnatnp -funroll-all-loops -march=native regexdna.adb

  Running time of ./regexdna: 32 seconds.

  Comment:
  Now the compiler uses the g-spipat.ads (Gnat.Spitbol.Pattern)
  in the working directory, ignores the one in adainclude, and
  recompiles the Spitbol packages.  The 32 seconds is almost the
  same as the running time of the GNAT GPL compilation. (Actually,
  the GNAT GPL compilation runs in 30.5 sec if Stack_Size is 37
  instead of 129. So it is a bit better, but not nearly as much
  as I thought.)

>
>While changing the library is not part of the game,
>this is useful in general, I'd think, since the
>comment next to Stack_Size invites us to adjust it to
>fit a program's needs.
>

Well, I do advocate using a modified g-spipat.ads.
Just append the modified g-spipat.ads to regexdna.adb,
give the usual gnatchop instruction, and the -a switch
for gnatmake.

It seems to me that this is completely kosher.

Looking (quickly) through the other submissions, I see
several common practices: writing your own library modules,
linking to language standard library modules, and linking
to various to 3rd party library modules that have
nothing to do with a particular language standard.

I notice for example that fortran and pascal submissions
will simply append their own source code versions of
hashing modules. The language doesn't provide them.

Another practice is to link with the boost library
for regex or for threads.  Some link to OpenMP for
multiprocessing IIUC.  The Ada pidigits.adb even
links to GMP using interfaces.C.

Jonathan