deprecating -Ounchecked

I don’t have any issue with moving it to a -unsafe-remove-checks flag, but the idea of removing support for it altogether causes some alarm.

As a quick data point, I ran my game engine/project with the same workload for a few minutes with “Disable Safety Checks” on and off in Xcode, with no other flags changed.

The average CPU usage (not the best metric but the easiest to acquire) on my iMac (4.0GHz i7) hovered between ~78-82% across all cores with safety checks off, while it averaged between ~88-92% with safety checks on. That’s a fairly significant performance deficit. I’ve attached screenshots below.

It’s worth noting that I’d expect that gap to be even larger if I hadn’t manually disabled safety checks (e.g. using &+ and &*) in a number of places to make debug mode usable.

With “Disable Safety Checks” set to “No”:

With “Disable Safety Checks” set to “Yes”:

Thomas

···

On 4/11/2017, at 8:45 AM, Slava Pestov via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> 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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev