Re: gcc, AVX (and newer) intrinsics and binutils
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
> 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
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
> 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
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
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&item=gcc7-clang4-jan&num=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
