Re: FreeBSD Compiler Benchmark: gcc-base vs. gcc-ports vs. clang

On Thu, Mar 10, 2011 at 10:33:37PM +0100, Martin Matuska wrote:
> Hi everyone,
> 
> we have performed a benchmark of the perl binary compiled with base gcc,
> ports gcc and ports clang using the perlbench benchmark suite.
> Our benchmark was performed solely on amd64 with 10 different processors
> and we have tried different -march= flags to compare binary performance
> of the same compiler with different flags.
> 
> Here is some statistics from the results:
> - clang falls 10% behind the base gcc 4.2.1 (test average)
> - gcc 4.5 from ports gives 5-10% better average performance than the
> base gcc 4.2.1
> - 4% average penalty for Intel Atom and -march=nocona (using gcc from base)
> - core i7 class processors run best with -march=nocona (using gcc from base)
> 
> This benchmark speaks only for perl, but it tests quite a lot of
> "generic" features so we a are seriously considering using ports gcc for
> heavily used ports (e.g. PHP, MySQL, PostgreSQL) and suggesting that an
> user should be provided with a easily settable choice of using gcc 4.5
> for ports.
> 
> A first step in this direction is in this PR (allowing build-only
> dependency on GCC):
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155408
> 
> More information, detailed test results and test configuration are at
> our blog:
> http://blog.vx.sk/archives/25-FreeBSD-Compiler-Benchmark-gcc-base-vs-gcc-ports-vs-clang.html

Putting the 'speed' question completely aside, I would like to comment
on other issue(s) there. The switching of the ports to use the port-provided
compiler (and binutils) would be very useful and often talked about feature.

Your approach of USE_GCC_BUILD as implemented is probably not going
to work. The problem is that gcc provides two libraries, libgcc and
libstdc++, that are not forward-compatible with the same libraries from
older compilers and our base.

libstdc++ definitely did grown new symbols and new versions of old
symbols, and I suspect that libgcc did the same. Also, we are trusting
the ABI stability premise.

For this scheme to work, we at least need a gcc-runtime port with dsos
provided by full port, and some mechnanism to force the binaries
compiled with port gcc to use gcc-runtime libs instead of base.
Might be, -R<path> linker cludge.