// In order to reproduce/understand the issue meant to be
// demonstrated by this program:
//
// Note the difference (in reported time measurements) of declaring
// `let a = Double(1)` at top level or within test()
//
// Also note that `a.binade` is a constant, which I'd expect the optimizer to
// hoist out of the loop, just like it does if we use eg `.magnitude` instead
// of `a.binade`.
//
// Examine the effects of the 2*2 = 4 ways of combining these modifications.
//
// I'm using Development Snapshot 2018-05-30.
// The issues are worse and different with eg def toolchain of Xcode 9.4.

import AppKit

let a = Double(1) // <-- See diff in times when this is within test() instead.

func test() {
    for _ in 0 ..< 5 {
        var checksum = UInt64(0)
        let t0 = CACurrentMediaTime()
        for _ in 0 ..< 1_000_000_000 {
            let v = a.binade // <-- Compare with eg `.magnitude`.
            checksum = checksum &+ v.bitPattern
        }
        let t1 = CACurrentMediaTime()
        print(t1 - t0, "seconds, checksum:", checksum)
    }
}
test()

//-----------------------------------------------------------------------
// test.swift - Demonstrating a Swift 4.1(?) performance regression
//-----------------------------------------------------------------------
//
// This program demonstrates a huge increase in execution time when
// compiled with recent versions of the compiler. 
//
// Here's what I see on my MacBook Pro, 2 GHz Intel Core i7:
//
// Compiling with Xcode 9.2:
//
// › sudo xcode-select -s /Applications/Xcode.app/
// › xcrun swiftc --version
// Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)
// Target: x86_64-apple-macosx10.9
// › xcrun swiftc -O -whole-module-optimization -static-stdlib test.swift
// › ./test
// 0.0111292660003528 seconds, checksum: 6917529027641081856
// 0.0125824180140626 seconds, checksum: 13835058055282163712
// 0.0109889880113769 seconds, checksum: 2305843009213693952
// 0.00988745299400762 seconds, checksum: 9223372036854775808
// 0.0114470749977045 seconds, checksum: 16140901064495857664
//
// Compiling with Xcode 9.3 beta 3:
//
// › sudo xcode-select -s /Applications/Xcode-beta.app/
// › xcrun swiftc --version
// Apple Swift version 4.1 (swiftlang-902.0.41 clang-902.0.31)
// Target: x86_64-apple-darwin17.4.0
// › xcrun swiftc -O -whole-module-optimization -static-stdlib test.swift
// › ./test
// 5.08630971799721 seconds, checksum: 6917529027641081856
// 5.10243050198187 seconds, checksum: 13835058055282163712
// 5.09426819198416 seconds, checksum: 2305843009213693952
// 5.06536405498628 seconds, checksum: 9223372036854775808
// 5.08944137202343 seconds, checksum: 16140901064495857664
//
// (The results are the same when doing release builds within Xcode,
//  and I have not tested any versions of the compiler between the default
//  toolchains of Xcode 9.2 and Xcode 9.3 beta 3. Recent dev snapshots
//  show approximately the latter (slow) results).
//
// Note that the particulars (for-loop, `Double`'s `.binade`, etc) of
// this program have been chosen just because they make for a simple
// demonstration, and that the situation where I first encountered the 
// broader issue that I guess is behind this example, was very different,
// and of course not as contrived.
//
// You can for example replace `Double` with `Float` and `.binade` with
// `.nextUp`, `.ulp` or `.significand` and see that the results are
// pretty much the same, but note that eg `.magnitude` and `.squareRoot()`
// are not affected by this regression. I would guess that many other
// types, properties and methods would demonstrate similar erratic
// behavior of the optimizer.
//
// From my perspective as humble Swift programmer, I'd like to be able to
// trust the compiler to for example hoist `let v = a.significand` out of
// the for-loop for me, computing it only once, since it should be possible
// for the compiler to know that it is a constant value. But note that this
// isn't happening even in the "fast" Xcode 9.2 version of the compiler
// (since manually moving `let v = a.significand` out of the inner for-loop
// will further improve the reported times, from 0.01 seconds to around
// 1.0e-08 seconds). But I guess this can't be generally expected until
// Swift offers a proper way to mark and track side effects.
//
// Anyway, I'd like to at least be able to trust a new version of the
// compiler to not suddenly make some of my code 500 times slower!
//
// Therefore I'm wondering if there are any unit tests that catches this
// sort of performance regressions? Perhaps they are not gone through
// until the full testing that is performed for official releases?
//
// Related discussion here:
// https://forums.swift.org/t/missed-optimization-opportunity/10381
//-----------------------------------------------------------------------

import AppKit

let a = Double(1)
var checksum = UInt64(0)
for _ in 0 ..< 5 {
    let start = CACurrentMediaTime()
    for _ in 0 ..< 1_000_000_000 {
        let v = a.binade
        checksum = checksum &+ v.bitPattern
    }
    let stop = CACurrentMediaTime()
    print(stop - start, "seconds, checksum:", checksum)
}