[swift-dev] deprecating -Ounchecked

[Erik Eckstein]

> On Nov 2, 2017, at 1:56 PM, Thomas Roughton via swift-dev <swift-dev at swift.org> 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 <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
> 
>> 
>> 
>>> On 2 Nov 2017, at 1:33 pm, Erik Eckstein <eeckstein at apple.com <mailto:eeckstein at apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johannesweiss at apple.com <mailto:johannesweiss at apple.com>> 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 <swift-dev at swift.org <mailto:swift-dev at swift.org>> 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 at swift.org <mailto:swift-dev at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171103/d79b87bb/attachment.html>