Benchmarks results for Compilers on FreeBSD 11

[K. Macy]

On Mon, Aug 29, 2016 at 4:46 PM, Erich Dollansky
<erichsfreebsdlist at alogt.com> wrote:
> Hi,
>
> Micheal continued:
>
> http://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-OpenMP-Base
>
> I just wonder if not enabling an option in base because the option is
> not required in base would make the documentation of the program
> useless except it is documented. The problem here is now that e.b. I
> look typically for information of a program at the program's site. I
> do not think that they care there what FreeBSD makes out of the
> program.
>
> With other words, it creates confusion.

I also don't understand why I need a system compiler and ports
compiler when the system compiler is a strict subset of the ports
compiler. Spending half of my buildworld time compiling llvm and
friends has always been a bit annoying, but now I find that it's not
even complete. I'd just as soon install devel/llvm38 from ports and
use the external toolchain support (that is if it worked for llvm38).
The strongest reason I've heard for bundling a compiler in src is the
instability of the C++ ABI (which is completely defeated when you
knowingly make the base compiler inadequate for some purposes). The
others are "we've always done it that way", "we need a compiler to
build the system" (a prebuilt package does that just find), and the
best "Solaris didn't include a compiler and look what happened to it"
(last I looked the Linux kernel didn't come bundled with gcc and as
far as I can tell the Linux community is doing just fine).


OpenMP is not a new technology and some widely used ports like fftw
and openblas can make use of it ... but don't on FreeBSD because that
requires pulling in gcc (and in this case an old one).

I can't speak for the whole universe of users, but I think it's safe
to say that most users are not power users who individually configure
ports tailored to their needs. I think my experiences on Ubuntu, where
I'm definitely not a power user, are illustrative. I never compile
*anything* that has a package in an ubuntu repo and I assume that the
packages are configured when built to enable any performance options
that don't potentially cause stability issues. Similarly, on FreeBSD
most users are going to be using packages and they're going to assume
that the packages are configured to "provide the best user
experience". Consequently anyone using a package that could use OpenMP
is going to legitimately just assume that "X" is slower on FreeBSD.
And for all intents and purposes "X" _is_ slower.


Similarly, -fopenmp automatically pulls in libgomp with gcc and
-openmp pulls in libiomp with icc. Neither updating the makefile nor
creating a wrapper around clang/clang++ to pass the library path is
difficult. However, the need to do so is essentially a regression with
respect to other platforms and thus can safely be labelled as being
"broken". It gratuitously creates yet another small, but real hurdle
for users.



-M