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. -landonf _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
