Re: [Bug-gnubg] Some questions about build options and toolchain

[Michael Petch]

On 2015-01-17 4:39 PM, Philippe Michel wrote:
> When building gnubg, there is some automake magic to have some files in
> the lib directory compiled with different flags from the rest.
>
> Is it really needed or is it a relic from early SSE days, trying to
> build a unique binary with both SSE and non-SSE evaluation routines and
> the right one selected at runtime ?

I believe it is a relic. At some point I believe the intent was to have
different shared objects or DLLs for each of the supported types. At run
time you could in theory check for the best available option and use it.
Of course there is a bit of a penalty with the extra level of
indirection. Some of our downstream maintainers have been curious if we
were looking at supporting that.
>
> On my machine, I compile with -march=native -mtune=native, get SSE
> instructions everywhere, not just in libsimd_la-XXX objects and
> everything works fine.
>
If you use those parameters to GCC then it will compile all the modules
with whatever settings are specific to the architecture (not just the
lib) directory. So yes, it should work. Of course if you build for one
architecture (let us say it allows AVX) and try to run those binaries on
a non-AVX system (or a system without OS support for AVX) it will fail.
This likely isn't an issue for people who build from source, but this
has caught some of our downstream maintainers off guard until it was
pointed out to them.

>
> Second question, for those who make binary packages for various
> distributions :
>
> With gnubg, the -O3 compilation flag brings a significant speed
> improvement. -ffast-math helps as well.
>

I build binaries for OS/X and Windows and I actually use -O3. I override
it during the configure process. I haven't used -ffast-math but if it
brings improvement I could adjust my configure options.

> What is your policy about such flags in upstream sources ? Do you follow
> them ? Override them ? Take them as a hint and decide on a case by case
> basis ? I suppose the issue alredy happens with numerical libraries,
> audio and video processing code, etc...
>

Well we are upstream. So we can set whatever defaults we wish to, but
they should still be over-ridable at compile time (via configure). Often
distros will override them anyway to produce code that is more inline
with their environment. Some distros prefer to have a pile of gcc
options to be anal about security (even if it might be a performance
penalty). Some distros may default to -O2 . However most distros allow
for their package build process to overrride things on a case by case
basis. ie: -O2 may be the norm across most programs but -O3 can be used
for a specific application. I don't know how often that happens.

If our configure process or build environment isn't suited to how they
do builds they will often create a patch(es) that are applied to a raw
source tar ball to provide the functionality they need before they do
their autogen/configure/make. Over time I have been known to take
patches used by distros and apply them to our upstream code and then let
the distro know their patch isn't needed.

> Finally, would it cause trouble to someone if gnubg was build as C99
> code (-std=gnu99 really, since it would have to cater with embedded asm).
>

Embedded assembler would be a concern (so you wouldn't be able to use
-std=c99 for the reason you point out). I guess I should point out that
whatever code we have should probably still be a compilable with
Microsoft VC++ (in a Win32 environment). I believe people like Jon
Kinsey still do such builds and we do maintain separate make files for it.

MSVC as far as I know is C99 (or supports it) and also supports inline
assembly as we currently do it. I can't think of any other gnu C99
feature we'd use that wouldn't be supported on either compiler. So this
is probably a non-issue. The only reason I brought it up was because GCC
wasn't the only target compiler (but in this case it likely makes no
difference).

I build GNUbg Win32 binaries with GCC so that really isn't an issue for
me specifically.

That was my 5 cents (Canada doesn't make pennies anymore). I'd ask Russ
Allbery the Debian downstream maintainer for GNUbg for his thoughts on
some of this. Russ has been a big asset to our product over the years.

-- 
Michael Petch GNU Backgammon Maintainer / Developer OpenPGP
FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304