Re: gcc, AVX (and newer) intrinsics and binutils

[René J . V . Bertin]

Christopher Jones wrote:

> provides a rock solid gcc build that works in all cases without any nasty
> nuances (such as the library linkage changes you recently posted).

I have now been able to build and run KDevelop 5.1.1, digiKam 5.5.0 and 
port:boost with my patched G++


Boost needs some patching itself, to remove the presumption that libc++ is only 
used with clang:
https://trac.macports.org/ticket/54176

R.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gcc, AVX (and newer) intrinsics and binutils

[Andrew Moore]

> On May 13, 2017, at 2:58 PM, René J. V. Bertin  wrote:
> 
> Christopher Jones wrote:
>> such that I am not really sure
>> its warranted to expend a lot of effort to keep gcc alive on OSX, when
> 
> There appear to be quite a few ports that use/expect gcc, though. For some 
> that 
> is just to get a Fortran compiler, but if memory serves me well you cannot 
> just 
> build/install gfortran with gcc and g++. Even without official maintainer the 
> ports are kept up-to-date, and I'd argue that we could just as well add an 
> option to make the C and C++ compilers a viable alternative. As a variant, at 
> least for the time being.

Ouch!  Let’s put that into stronger terms:  Christopher Jones, your comment is 
full of hubris and exceedingly pretentious.   To suggest not supporting GCC on 
OS X/macOS is not only bad policy, it is dangerous and reflects profound 
ignorance.
-AM
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gcc, AVX (and newer) intrinsics and binutils

[René J . V . Bertin]

Christopher Jones wrote:

> My reading is there is, on average across the board, there is no clear
> advantage/disadvantage to either gcc or clang

That's exactly what I'm saying too. However, that's all on Linux where clang 
may 
not perform optimally (because using libstdc++) and where GCC can use an up-to-
date gas. And it's with synthetic benchmarks.

> such that I am not really sure
> its warranted to expend a lot of effort to keep gcc alive on OSX, when

There appear to be quite a few ports that use/expect gcc, though. For some that 
is just to get a Fortran compiler, but if memory serves me well you cannot just 
build/install gfortran with gcc and g++. Even without official maintainer the 
ports are kept up-to-date, and I'd argue that we could just as well add an 
option to make the C and C++ compilers a viable alternative. As a variant, at 
least for the time being.

> not accept any patches into MacPorts for this unless they a) do not require
> significant patching of the gcc builds that upstream does not accept and 

The patch is significant in its implications, not quite in its implementation 
or 
even the underlying principle. Libc++ and libstdc++ are independent 
implementations of the same standard that just happen not to be exchangeable 
without recompiling. Patching GCC so that it links to the other isn't rocket 
science. Getting it to use the corresponding headerfiles can actually be done 
without patching at all; I'm currently doing it only to ensure that the correct 
headers are found when GCC is being built itself.

Now, is upstream likely to accept it? That's a whole different question, for 
all 
I know they might have an agenda against libc++ or the Mac platform like Apple 
have against GPL-3 (and which is the main reason we have clang and not GCC any 
more). The patch is a typical distribution patch and will thus come across a 
bit 
of a hack in upstream eyes. An upstreamable version would need a configure 
option 
to activate it and one to specify the location of clang's header files, and 
would 
presumably suppose that the libc++ version is recent enough (or else avoid 
using 
certain functions).
I've requested to register for a GCC bugzilla account to see what they think 
and 
what ideas they have to improve my implementation but haven't heard back yet.



> b)
> provides a rock solid gcc build that works in all cases without any nasty
> nuances (such as the library linkage changes you recently posted). If you can

Remind me what you mean with that?

I've been building a few more ports

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gcc, AVX (and newer) intrinsics and binutils

[Christopher Jones]

> Either way, benchmarks like these are rarely representative of real-world 
> performance in *[y]our* workloads. My own experience over the years has been 
> that GCC gives measurably better performance and that in cases where every 
> last 
> drop doesn't count you were better off using clang because it compiled so 
> much 
> faster. The differences have been disappearing but clang still doesn't win 
> across the board with a clear advance.
> 
> That's enough for me in itself as an argument to try to make GCC integrate 
> and 
> perform as well as possible on Mac, because some users might benefit. Hence 
> my 
> interest in support for the AVX (and newer) instruction sets.

Funny how the same data can lead to very different conclusions with different 
people. 

My reading is there is, on average across the board, there is no clear 
advantage/disadvantage to either gcc or clang, such that I am not really sure 
its warranted to expend a lot of effort to keep gcc alive on OSX, when upstream 
have clearly placed themselves 100% in the clang boat. That said, you are of 
course completely free to experiment yourself but I would say we should not 
accept any patches into MacPorts for this unless they a) do not require 
significant patching of the gcc builds that upstream does not accept and b) 
provides a rock solid gcc build that works in all cases without any nasty 
nuances (such as the library linkage changes you recently posted). If you can 
do both of these, great, but I admit I am quite dubious.

Chris

smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gcc, AVX (and newer) intrinsics and binutils

[René J . V . Bertin]

To answer my own question, partly: binutils doesn't install an assembler on 
Mac. 
Bummer, so it cannot provide the answer to the intrinsic instructions issue...

I was a bit surprised to find out that the CCTools as is still based on GNU as, 
but an *old* version.

R.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gcc, AVX (and newer) intrinsics and binutils

[René J . V . Bertin]

Chris Jones wrote:

> 
> 
> 
>> GCC vs. clang comparisons on sites like Phoronix suggest that GCC still has
>> the upper hand compared even to clang 4.0 in computation-intensive tasks so
>> it would make a lot of sense to get it to support the full instruction set.
> 
> 
> Please provide links to support such a claim. 

Ok, I should have written "seems to have the upper hand ... in many computation-
intensive tasks".

> My reading is the
> comparison is far from as clear cut as you make out. For instance
> 
> http://www.phoronix.com/scan.php?page=article=gcc7-clang4-jan=1
> 
> OK, thats from january, with a prelease gcc 7 version. Its the newest I
> have found though...

I've seen the same test, and yes, it's not a clear-cut situation. Those 
Phoronix 
tests usually seem to lack a comprehensive summary that doesn't require staring 
hard at a table like 

WINS:
Clang 3.9.1: 12  [25.0%]
Clang 4.0 SVN:   9   [18.8%]
GCC 4.9.4:   7   [14.6%]
GCC 7.0.0 20170108:  7   [14.6%]
GCC 5.4.0:   7   [14.6%]
GCC 6.3.0:   6   [12.5%]

LOSSES: 
Clang 3.9.1: 13  [27.1%]
GCC 5.4.0:   12  [25.0%]
GCC 4.9.4:   7   [14.6%]
GCC 7.0.0 20170108:  7   [14.6%]
Clang 4.0 SVN:   7   [14.6%]
GCC 6.3.0:   2   [4.2%]

Either way, benchmarks like these are rarely representative of real-world 
performance in *[y]our* workloads. My own experience over the years has been 
that GCC gives measurably better performance and that in cases where every last 
drop doesn't count you were better off using clang because it compiled so much 
faster. The differences have been disappearing but clang still doesn't win 
across the board with a clear advance.

That's enough for me in itself as an argument to try to make GCC integrate and 
perform as well as possible on Mac, because some users might benefit. Hence my 
interest in support for the AVX (and newer) instruction sets.


R

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev