Benchmarks results for FreeBSD 11

[Johannes Dieterich]

On Sun, Aug 28, 2016 at 11:16 AM, Fernando Herrero Carrón
<elferdo at gmail.com> wrote:
> El 28/8/2016 14:56, "Dimitry Andric" <dim at freebsd.org> escribió:
>>
>> On 28 Aug 2016, at 02:10, K. Macy <kmacy at freebsd.org> wrote:
>> >
>> >> The problem here is that Phoronix took a Beta version of FreeBSD 11.
>> >> Beta versions have a lot of debugging (malloc, invariants, witness)
>> >> options enabled which make it significantly slower than release
>> >> versions. This is even obviously when you run a Beta as a desktop. It
>> >> just feels much slower.
>> >
>> >
>> > I don't know what was going on in these particular tests, but in a
>> > more recent benchmarking run
>> >
>> > -https://www.phoronix.com/scan.php?page=article&item=freebsd11-clang-gcc&num=1
>> > - you're seeing the result of openmp being disabled in base. The clang
>> > maintainer for src refuses to include libomp as required for -fopenmp
>> > because nothing in base requires it.
>>
>> Come on, this is nonsense.  I have indicated earlier that I would have
>> liked to import openmp into base, but this was shot down precisely for
>> that reason: nothing in base uses it.
>>
>> So for now, the solution is simply: install one of the llvm ports, and
>> use it.  These have configuration setting to install every optional
>> component from the LLVM project.
>>
>> -Dimitry
>>
>
> How does the port infrastructure handle openmp-enabled ports (those with an
> openmp option) then? Is an omp-capable compiler automatically pulled in or
> is openmp ignored unless the port explicitely requests one from ports?
If you set compiler:openmp, it currently defaults to pull in lang/gcc.
So, even if the port would be perfectly happy to compile with llvm, we
rely on gcc. If the port is an important library such as openblas or
fftw3, this then in turn causes all the well documented issues for
software using that library. So we should rely on, at the very least,
lang/llvm38 to be used for these cases. However, that does not work
out of the box as those ports do not find their own libraries (libomp
is the important one here) by themselves, requiring alterations to
every single make system (as the rest of the world correctly assumes
that -fopenmp enables OpenMP) to add the link path. If that vaguely
reminds you of the -Wl,-rpath=/usr/local/lib/gcc48 insanity, you'd be
right.

All of this may be why important ports (openblas, fftw3, ImageMagick)
do not enable OpenMP by default, leaving us with sub-par performance
not only in benchmarks such as the one cited above.

It is a dreadful situation in my opinion and is not helped by the fact
that we do not even acknowledge there to be an issue. I happen to
require working OpenMP support on a day-to-day basis, are required to
jump through hoops to get it, and it seems decisions are made without
assessing the impact of them for people like me.

Sorry

Johannes