> 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
