On Jul 30, 2013, at 9:13 AM, Landon J Fuller <[email protected]> wrote:
> On Jul 30, 2013, at 8:59 AM, Vincent Habchi <[email protected]> wrote: > >> Hi! >> >>> I'm concerned that the net performance gain here is going to be far >>> outweighed by the maintenance costs and user complexity. Without actually >>> measuring the gains, there's no guarantee that these changes will actually >>> improve performance, and in moving away from the optimization flags et al >>> selected by the original developers, could very possibly trigger bugs in >>> code generation output (e.g., compiler bugs, especially with bleeding-edge >>> clang), or reveal bugs in the project that aren't apparent at lower >>> optimization levels. >> >> Well, clang-3.3 is, in principle, well known and (almost) bug free. It’s a >> full release version, not a bleeding edge compiler anymore… > > Higher optimization levels (and in some cases, normal optimization levels) > often trigger buggy code generation, *especially* in a compiler as young as > clang. > >> as for bugs in the project… well… they will have to be unearthed sooner or >> later anyhow. > > Unfortunately having these kinds of bugs unearthed by end-users via unusual > compiler and optimization selections is unlikely to be particularly useful to > the project in question, and will be costly to users. > >> Remember that the perf variant is going to be optional anyhow, so we could >> easily restrict its use to the most advanced users. > > As a developer, I think it's more conservative to not provide a potentially > failing option except in cases where it's demonstrated through profiling to > actually provide a significant performance advantage. It's quite possible > that it could just as well introduce performance regressions, rather than > actual improvements. We also have devel versions of many ports (including clang-3.4) which are bleeding edge. This makes it easier for advanced users to test it and fix the bugs. I say leave it in as a non-default variant with a WARNING in the description. Cheers! Frank _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
