[m-users.] Link-time optimization

[Massimo Dentico]

On 13/06/2020 04:09, M McDonough wrote:
> It's not just enough to put the LTO flags in the CFLAGS, since the
> standard library (which accounts for much of the executable size in my
> experience).
> 
> There is an LTO option during configuration, although I only seriously
> tested it for MSVC since that's my main target on Windows and shared
> libraries aren't possible with Mercury in that configuration. That
> will reduce the resulting exe file by quite a lot.

Thanks a lot, I completely missed it the last time I looked at the 
output of "./configure --help" (maybe it wasn't there before version 20?)

Ok, I'll try restarting from scratch and passing "--enable-lto" to 
"./configure".


> The LTO flags are implemented for gcc and clang as well as MSVC, but I
> am unsure if it's done in an optimal way (a large part of why it's
> marked as experimental I believe).
> 
> Using LTO will also cause the linking steps to be quite long, since
> it's basically compiling the entire Mercury runtime and standard
> library at that point.

Yes, my experience with compiling other software with LTO is that
compilation is a bit faster and linking is slower. I would like to try
to pass "-fno-fat-lto-objects" to GCC:

 
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fwhole-program
    Note that when -fno-fat-lto-objects is enabled the compile stage is
    faster but you cannot perform a regular, non-LTO link on them.

But if passing "-flto" in CFLAGS is not effective, I think that passing
"-fno-fat-lto-object" will also not be effective. But I can be wrong:
my experience with Autotools is limited, I have always used them as a
black-box.


> ...................... But the file size is quite a bit smaller. The
> actual performance change is pretty minor from my experience over just
> intermodule optimization, since intermodule-optimization tends to be
> very effective before the actual grade's compiler even gets the code.

Well, I was attracted to Mercury for the performance of the executables 
produced by its compiler compared to Prolog interpreters/compilers, so 
at the moment I'm more interested in producing executables of reasonable 
size.

Next I'll investigate how much the tools based on Datalog variants (e.g. 
Soufflé) are apt to the task of high-level intermediate target for 
specifications-as-programs (business rules, ontologies and so on) and 
what are their performances.

It's unfortunate that Mercury is missing in this comparison of
declarative systems:

    * Benchmarks of Deductive Database Systems, Relational Databases, 
and Graph Databases – Introduction to rbench
    http://dbs.informatik.uni-halle.de/rbench/

--
Massimo A. Dentico