Re: [lmi] Inchoate support for GNU/Linux builds with lmi makefiles

[Greg Chicares]

On 2018-11-16 11:53, Vadim Zeitlin wrote:
> On Fri, 16 Nov 2018 11:03:40 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> [TL;DR: export LD_LIBRARY_PATH and use '-fPIC'; then everything works]
> 
>  Nice!

The next step is to apply ideas such as you had suggested:

  https://lists.nongnu.org/archive/html/lmi/2017-05/msg00034.html
| I put host-specific
| stuff in a directory called ${uname}-${uname -m} and I add a "-compiler"
| suffix when more than one ABI is used. So I can have directories like
| Linux-x86_64-clang, Linux-x86_64-gcc6 and even Linux-x86_64-suncc

to the present build-directory structure. For '--host=i686-w64-mingw32' (only),
we now have:

  build/lmi/$(uname)/gcc/safestdlib
  build/lmi/$(uname)/gcc/ship
  build/lmi/$(uname)/gcc/so_test

But is $(uname) ever really useful here? I've built i686-w64-mingw32 lmi in
  build/lmi/CYGWIN  [years ago, with native msw]
  build/lmi/Linux   [these days, cross-compiling on my debian machine]
but those were all the same i686-w64-mingw32 binaries, regardless of the OS
that I happen to be running. IOW, out of the usual autoconf
  {build, host, target}
triplet, I think all I need care about is "host", because directories
  build/lmi/Linux-build/msw-host
  build/lmi/Cygwin-build/msw-host
would contain the same stuff. Probably the only host types that matter are:
 - x86_64-linux-gnu (because there's no need for i686-linux-gnu); and
 - i686-w64-mingw32 or x86_64-w64-mingw32 (only the former for now, but
     only the latter once we move to 64-bit msw production builds).

And specifying "lmi" in build/lmi doesn't add anything either. (It did when
we had two svn trunks, "lmi" and "skeleton", but those days are long gone.)

Dropping what doesn't matter, and adding the compiler, would yield a
directory-structure grammar like this:

  build /
    {x86_64-linux-gnu, i686-w64-mingw32, x86_64-w64-mingw32} /
    {gcc, clang} /
    {safestdlib, ship, so_test} /

where we could later adjust the options enumerated in {}, e.g.,

  build/x86_64-linux-gnu/gcc/asan

for "address sanitizer".

> GC> On 2018-11-16 01:44, Vadim Zeitlin wrote:
> GC> > On Thu, 15 Nov 2018 23:52:44 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> On 2017-04-12 00:07, Greg Chicares wrote:
> GC> [...]
> GC> > GC> adds '-Wno-useless-cast' to ignore a pervasive boost-1.33.1 problem,
> GC> > 
> GC> >  I wonder why was it necessary when we already have a pragma disabling 
> this
> GC> > warning in boost_regex.hpp.
> GC> 
> GC> Because the boost filesystem library also needs it with gcc-8.2.0
> GC> for x86_64-linux-gnu, e.g.:
> 
>  Hmm, I see, it looks like I just don't have -Wuseless-cast enabled for the
> autotools build, which is why I didn't need it. Now I don't know if I
> should enable it there or if it's better to live without it, finally, as
> this warning doesn't really seem very useful to me.

It's neither the most useful warning, nor entirely useless. I'll keep it
myself, blocking it where expedient, but I don't see a strong case for
asking you to enable it yourself.

> GC> make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 
> -Wno-pedantic' CFLAGS='-m64' LDFLAGS='-m64' unit_tests 
> unit_test_targets=global_settings_test
> 
>  BTW, isn't "-g" missing in LDFLAGS here? AFAICS you won't be able to debug
> the binaries built by this command.

  https://sourceware.org/binutils/docs/ld/Options.html
| -g   Ignored. Provided for compatibility with other tools.

I've never used it with gnu ld. (Does it matter for clang though?)

> GC> We use boost::regex in so few cases that we created a 'boost_regex.hpp'
> GC> header with pragmata to suppress warnings. But we use boost::filesystem
> GC> so widely as to render such a technique far less attractive.
> 
>  And, also, it should be replaced with std::filesystem, which hopefully
> won't give this warnings (but I didn't check this yet).

However, IIRC, std::filesystem isn't a mere drop-in replacement
(due to check_native() for instance).

> GC> BTW, 32- vs. 64-bit speed comparison:
> [...]
> 
>  This certainly looks like a nice speedup, I didn't expect it, to be
> honest. I wonder if you'd be willing to rebuild it with -O3 just out of
> curiosity?

TL;DR: Run time is unaffected: '-O3' doesn't help.

Many of the statistics 'make cli_tests' reports are small integral
numbers of milliseconds, so let's ignore those and compare only
the more precise 'solve speed':

make $coefficiency build_type=native CXXFLAGS='-O2 -ggdb -m64 -fPIC 
-Wno-pedantic -Wno-useless-cast' CFLAGS='-m64 -fPIC' LDFLAGS='-m64 -fPIC' 
cli_tests 2>&1 |grep 'solve speed'

Test solve speed: 8.062e-03 s mean;       7066 us least of  13 runs
Test solve speed: 3.984e-02 s mean;      39751 us least of   3 runs

Reformatting those timings as a single row, and adding rows for
four more runs, gives:

0.008062        7066    0.03984 39751
0.008191        7012    0.03957 39445
0.008194        7025    0.03949 39311
0.008168        7231    0.03983 39740
0.007132        6970    0.03949 39428

Same command, but with -O3 instead of -O2 in CXXFLAGS:
                        
0.007726        7057    0.03934 39280
0.007952        7058    0.04001 39873
0.007908        7045    0.03970 39507
0.008349        7113    0.03932 39242
0.007003        6916    0.03958 39442

One minus '-O2'/'-O3':
                        
4%      0%      1%      1%
3%      -1%     -1%     -1%
4%      0%      -1%     0%
-2%     2%      1%      1%
2%      1%      0%      0%

The left two columns are the antediluvian fork; the right two are
the lmi production system. The largest relative difference is in
the rightmost column: i.e., the less-important antediluvian fork,
and the less-robust mean statistic. Conclusion: '-O3' brings no
meaningful advantage.