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.

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

Thomas

> On 3/11/2017, at 9:35 AM, Johannes Weiß via swift-dev <swift-dev@swift.org> 
> wrote:
> 
> 
> 
>> On 2 Nov 2017, at 1:33 pm, Erik Eckstein <eeckst...@apple.com> wrote:
>> 
>> 
>> 
>>> On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johanneswe...@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@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@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

Reply via email to