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