Re: [swift-dev] deprecating -Ounchecked

[Slava Pestov via swift-dev]

> On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev  
> wrote:
> 
> Random question: when did you introduce -Osize, and why didn’t it go through 
> the evolution process?  If this is a major flag that you expect users to 
> interact with (not some obscure debugging feature) then it is part of the 
> “UI" of Swift and seems subject to swift-evolution’s process.

Are compiler flags within the scope of the evolution process? -Osize has no 
effect on source compatibility or any other user-visible aspect of the language 
itself.

Slava___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] deprecating -Ounchecked

[Chris Lattner via swift-dev]

On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev  
wrote:
>>> 
>>> Deprecating would mean that we map -Ounchecked to -O.
>>> 
>>> If you have any comments or concerns, please let me know
>> 
>> What’s the motivation for this?  What problem does it solve?
> 
> There are several issues:
> First, Ounchecked does not come for free. To really support this mode we 
> would have to constantly track performance metrics for this, investigate 
> performance/codesize regressions, etc. This is a lot of effort.

That seems true regardless of how you spell it.

> So if we replace Ounchecked with an option -unsafe-remove-checks (similar to 
> -assume-single-threaded), as Johannes suggested, this is more like a “at your 
> own risk” thing (regarding performance). For example, it might happen that 
> users see perf regressions from one release to another, using this option.

I don’t see that.  It is either supported or not.  If it is unsupported, it 
should be removed.

> The second thing is, IMO, that -Ounchecked suggests that it’s just another 
> choice like -O. But I think we should encourage people to not use Ounchecked.

I don’t necessarily agree.  -Ounchecked isn’t “bad”.  It is a feature in 
service of a few specific use cases.  If you’d like to remove it, then you 
should publicly advertise that, and justify it based on the lack of users.  
Don’t cast value judgements against it and claim it should be removed on moral 
grounds.

> I think it’s fine if experienced developers, who know what they are doing, 
> use -unsafe-remove-checks, but we should not promote this mode in a prominent 
> place like in the -O namespace. This is just my personal opinion and I’m sure 
> some people have other opinions on this.

The cost of moving something exceed the cost of a simple “cleanup" IMO.

> The third issue is that we now have -Osize. The -unsafe-remove-checks would 
> be orthogonal to -O and -Osize.
> BTW, we should rename -O to -Ospeed for consistency (keeping -O as an alias 
> for -Ospeed).

Ok, well that’s an issue that can be resolved in multiple different ways, 
including changing how you introduced -Osize.

Random question: when did you introduce -Osize, and why didn’t it go through 
the evolution process?  If this is a major flag that you expect users to 
interact with (not some obscure debugging feature) then it is part of the “UI" 
of Swift and seems subject to swift-evolution’s process.

In short, I’d recommend that you pitch removing -Ounchecked on swift-evolution. 
 That seems like the path you want, because then you could completely remove 
the codepaths in question.

-Chris


___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] deprecating -Ounchecked

[Slava Pestov via swift-dev]

> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev  
> wrote:
> 
> So if we replace Ounchecked with an option -unsafe-remove-checks (similar to 
> -assume-single-threaded), as Johannes suggested, this is more like a “at your 
> own risk” thing (regarding performance). For example, it might happen that 
> users see perf regressions from one release to another, using this option.

I would suggest going further and removing the code for -unsafe-remove-checks 
altogether. Even untested code has a cost in terms of maintainability.

Slava___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

> On Nov 2, 2017, at 8:50 PM, Chris Lattner  wrote:
> 
> 
>> On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I’d like to propose to deprecate the -Ounchecked swift optimization mode.
>> 
>> The -Ounchecked mode actually contradicts one of the main goals of swift: to 
>> be a safe language.
>> In the past we didn’t see lot of significant performance differences 
>> compared to -O (there were some improvements but also some regressions).
>> Also, we want to reduce the effort of maintaining too many different 
>> optimization modes, especially because we recently added -Osize.
>> 
>> Deprecating would mean that we map -Ounchecked to -O.
>> 
>> If you have any comments or concerns, please let me know
> 
> What’s the motivation for this?  What problem does it solve?

There are several issues:
First, Ounchecked does not come for free. To really support this mode we would 
have to constantly track performance metrics for this, investigate 
performance/codesize regressions, etc. This is a lot of effort.

So if we replace Ounchecked with an option -unsafe-remove-checks (similar to 
-assume-single-threaded), as Johannes suggested, this is more like a “at your 
own risk” thing (regarding performance). For example, it might happen that 
users see perf regressions from one release to another, using this option.

The second thing is, IMO, that -Ounchecked suggests that it’s just another 
choice like -O. But I think we should encourage people to not use Ounchecked. I 
think it’s fine if experienced developers, who know what they are doing, use 
-unsafe-remove-checks, but we should not promote this mode in a prominent place 
like in the -O namespace. This is just my personal opinion and I’m sure some 
people have other opinions on this.

The third issue is that we now have -Osize. The -unsafe-remove-checks would be 
orthogonal to -O and -Osize.
BTW, we should rename -O to -Ospeed for consistency (keeping -O as an alias for 
-Ospeed).


> 
> Swift isn’t a "strict safety at all costs” language.  It is a pragmatic 
> language which aims to give people tools to solve problems.  One of the nice 
> things about -Ounchecked is that it provides an easy way to get a data point 
> about the cost of runtime checks.
> 
> -Chris
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] deprecating -Ounchecked

[Erik Eckstein via swift-dev]

> On Nov 2, 2017, at 1:56 PM, Thomas Roughton via swift-dev 
>  wrote:
> 
> A -1 from me to deprecating the mode. I’ve been using Swift in 
> high-performance situations such as in a game engine, where in particular 
> thing like integer overflow checks become a measurable cost in tight inner 
> loops. Currently I can’t use Array in many places due to ownership issues and 
> retain/release costs, but once that hopefully becomes feasible I’d also 
> definitely want the option to elide e.g. range checks. 
> 
> I’m aware there are alternatives to e.g. add without overflow checking with 
> &+ (which I use in some cases to make debug mode usable), but in general it’s 
> very useful to be able to test with these checks in debug mode and then have 
> them stripped in a release build once you’re reasonably confident they’re 
> safe. 
> 
> As a side note, if you’re only discussing renaming, I think it’s already 
> exposed as two separate options in Xcode: you have optimisation level 
> (mapping to -Onone, -O, -O,-wmo) and a separate ‘Disable Safety Checks’ 
> option. Mapping the compiler flags to match would I think make sense.

As I said, I like the idea from Johannes to add -unsafe-remove-checks, similar 
to -assume-single-threaded. I hope that’s ok with you.

> 
> I’m curious as to when you see performance regressions with -Ounchecked. Does 
> it limit the ability of the compiler to make some optimisations?

We didn’t actually investigate those regressions. But whenever the optimizer 
runs a different path it can happen that performance also regresses, even when 
it’s unexpected. For example, inlining decisions may change, which can have a 
big impact in both directions.

> 
> Thomas
> 
> On 3/11/2017, at 9:35 AM, Johannes Weiß via swift-dev  > wrote:
> 
>> 
>> 
>>> On 2 Nov 2017, at 1:33 pm, Erik Eckstein >> > wrote:
>>> 
>>> 
>>> 
 On Nov 2, 2017, at 10:51 AM, Johannes Weiß > wrote:
 
 Definitely a +1 from me, a haven't recently seen much of a difference 
 either.
 
 Said that I do sometimes use it in a micro-benchmark just to convince 
 myself we don't lose much performance on the checks. Usually it turns out 
 fine, I'm happy and move on. But I guess there's some value in being able 
 to elide a lot of checks just to see how much of a difference it does. And 
 if there's a big difference then I'd try to optimise the program and elide 
 unnecessary checks myself. Clearly -Ounchecked should never be used in any 
 real code but I find having a baseline when optimising performance very 
 helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline 
 for some code ;).
 
 And lastly I always thought having it as an 'optimisation' is a misnomer, 
 it's not an optimisation as it clearly changes the semantics of the 
 program quite a bit. I thought '-unsafe-remove-checks' or something 
 describes it better, a bit like '-assume-single-threaded’.
>>> 
>>> I like that idea. We could add such an option.
>> 
>> awesome, that's be a + from me then 
>> 
>> 
>>> 
>>> Daniel, I think that’s also what you were asking for.
>>> 
>>> 
 But probably the 'no checks' mode adds too much complexity to just keep it 
 around for a questionable way to do performance baselines.
 
> On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev 
> > wrote:
> 
> Hi,
> 
> I’d like to propose to deprecate the -Ounchecked swift optimization mode.
> 
> The -Ounchecked mode actually contradicts one of the main goals of swift: 
> to be a safe language.
> In the past we didn’t see lot of significant performance differences 
> compared to -O (there were some improvements but also some regressions).
> Also, we want to reduce the effort of maintaining too many different 
> optimization modes, especially because we recently added -Osize.
> 
> Deprecating would mean that we map -Ounchecked to -O.
> 
> If you have any comments or concerns, please let me know
> 
> Thanks,
> Erik
> 
> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev