[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why not 03 ?



On 01.06.2014 05:39, Steve Langasek wrote:
> On Sun, Jun 01, 2014 at 12:37:18AM +0200, Tollef Fog Heen wrote:
>> ]] Steve Langasek 
> 
>>> FWIW, the recent port of Ubuntu to ppc64el uses -O3 as the default, because
>>> IBM has broad experience in resolving performance issues for their own
>>> hardware and have found that -O3 gives an overall better experience for
>>> their customers.  It will be difficult for Debian to gather the same kind of
>>> information across all its architectures, but we shouldn't conclude, just
>>> because it's difficult to know the right answer, that -O2 is definitely the
>>> right answer.
> 
>> It sounds like we want to stop recommending any particular level in
>> Policy and just let the architecture toolchain default to the
>> recommended value for that architecture, and only override when there's
>> a need.
> 
> It seems that I believed the policy language on this to be much stronger
> than it actually is.  Looking at policy, I see:
> 
>      By default, when a package is being built, any binaries created should
>      include debugging information, as well as being compiled with
>      optimization.
> 
> It then presents CFLAGS = -O2 [...] as an example, but apparently this is
> only an example.
> 
> Still, I think we're better off improving the policy language to explain
> when we think -O3 should be used instead of -O2, and when it should not,
> rather than having a free-for-all in the archive.  Even to make this change
> on a per-architecture basis warrants more extensive profiling than porters
> are probably prepared to do; I certainly don't want maintainers to override
> it "when there's a need" without the project providing some guidance on what
> constitutes sufficient "need".
> 

I would not go into detail about O2 or O3 in the policy.
The meaning of these flags is very compiler specific. E.g. clang will
enable vectorization already at O2 and adds almost no extra passes with O3.

I think it would be better to simply state:
If the upstream optimization options differ from the ones of the default
debian toolchain it is recommended to override the debian defaults to
match the ones upstream uses during packaging.
Upstream usually has choosen particular options for a reason, they know
their software best.


Reply to: