cc @moiseev, @eeckstein

woodcrust (JIRA User) a few questions: did you compile with or without optimizations, as in, what were the compiler command line arguments? Also, do you mind invoking both compilers with `-emit-sil` option and attach the output to the jira? It would help diagnose the issue quicker.

Comment by Oleh (JIRA)

yes of course. Wait please a few minutes ...
p.s. I compiled with this command:
swiftc -O ./swift.swift -o ./path
because without optimization swift very slow. Slower than nodejs(~2,4) =)

Can confirm that, and it regressed a bit further with Swift 4.2:

(the jw-swift-VERSION is just a wrapper around xcrun that selects the right version; jw-dump-sil is just swiftc -frontend -emit-sil "$@" "$file")

for version in 4.0 4.1 latest; do rm -f test && echo running with $(jw-swift-$version swift -version) && jw-swift-$version swiftc -O test.swift && time ./test && jw-swift-$version jw-dump-sil -O test.swift > /tmp/$version.sil; done
running with Apple Swift version 4.0.3 (swift-4.0.3-RELEASE) Target: x86_64-apple-macosx10.9

real    0m1.706s
user    0m1.681s
sys 0m0.014s
running with Apple Swift version 4.1 (swift-4.1-RELEASE) Target: x86_64-apple-darwin17.6.0

real    0m2.150s
user    0m2.116s
sys 0m0.021s
running with Apple Swift version 4.2-dev (LLVM ff3ae623c3, Clang c2feda0b5c, Swift 58f7399ba5) Target: x86_64-apple-darwin17.6.0

real    0m2.214s
user    0m2.185s
sys 0m0.017s

attaching the sil files too

Comment by Oleh (JIRA)

I attached files with names:
emit-sil-4.0.3
emit-sil-4.1.1

latest test on

Linux cybertron 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64 GNU/Linux
with this simple code
https://github.com/woodcrust/puffin_bench/blob/master/source/1-sortArray/swift.swift
4.0.3 - 1,60 sec

4.1.1 - 2,27 sec

It's possible that the introduction of exclusivity checking for globals is impacting things here. If I change it so that the benchmark code is wrapped in a function, like this:

func shellsSort<T : Comparable>(_ arr: inout [T]) {
    let n = arr.count
    var gap = n/2
    var i = 0
    var j = 0
    var temp : T
    while gap > 0 {
        i = gap
        while i < n {
            temp = arr[i]
            j = i
            while (j >= gap && arr[j - gap] > temp) {
                arr[j] = arr[j - gap]
                j = j - gap
            }
            arr[j] = temp
            i = i + 1
        }
        gap = gap/2
    }
}

func main() {
  var a = [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]
  var c = 0

  while (c < 10000000) {
      shellsSort(&a)
      a = [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]
      c = c + 1
  }
}

main()

Then I see a 35% improvement, putting it back in line with the Swift 4 performance:

$ time ./with_function

real    0m1.469s
user    0m1.451s
sys 0m0.011s
$ time ./with_toplevel_code

real    0m1.982s
user    0m1.960s
sys 0m0.013s

We've seen a number of issues where "toplevel" code doesn't get optimized as well as standalone functions do. A lot of this is down to the underlying design flaw that top-level variables are treated like global variables and made visible to functions in other files, meaning we have to optimize them conservatively as if they can be modified from anywhere, when they should really be treated as local to the scope of the implicit toplevel entry point.

Comment by Oleh (JIRA)

⭐@jckarter

✔ cool thanks a lot, its work 😃