Swift Bêta de la performance: tableaux de tri

tl;dr Swift 1.0 est maintenant aussi vite que C par ce repère à l'aide de la version par défaut de l'optimisation du niveau de [-O].

---

Ici est un lieu de quicksort dans Swift Beta:

func quicksort_swift(inout a:CInt[], start:Int, end:Int) {
    if (end - start < 2){
        return
    }
    var p = a[start + (end - start)/2]
    var l = start
    var r = end - 1
    while (l <= r){
        if (a[l] < p){
            l += 1
            continue
        }
        if (a[r] > p){
            r -= 1
            continue
        }
        var t = a[l]
        a[l] = a[r]
        a[r] = t
        l += 1
        r -= 1
    }
    quicksort_swift(&a, start, r + 1)
    quicksort_swift(&a, r + 1, end)
}

Et la même en C:

void quicksort_c(int *a, int n) {
    if (n < 2)
        return;
    int p = a[n / 2];
    int *l = a;
    int *r = a + n - 1;
    while (l <= r) {
        if (*l < p) {
            l++;
            continue;
        }
        if (*r > p) {
            r--;
            continue;
        }
        int t = *l;
        *l++ = *r;
        *r-- = t;
    }
    quicksort_c(a, r - a + 1);
    quicksort_c(l, a + n - l);
}

À la fois le travail:

var a_swift:CInt[] = [0,5,2,8,1234,-1,2]
var a_c:CInt[] = [0,5,2,8,1234,-1,2]

quicksort_swift(&a_swift, 0, a_swift.count)
quicksort_c(&a_c, CInt(a_c.count))

//[-1, 0, 2, 2, 5, 8, 1234]
// [-1, 0, 2, 2, 5, 8, 1234]

Les deux sont appelés dans le même programme qu'à l'écrit.

var x_swift = CInt[](count: n, repeatedValue: 0)
var x_c = CInt[](count: n, repeatedValue: 0)
for var i = 0; i < n; ++i {
    x_swift[i] = CInt(random())
    x_c[i] = CInt(random())
}

let swift_start:UInt64 = mach_absolute_time();
quicksort_swift(&x_swift, 0, x_swift.count)
let swift_stop:UInt64 = mach_absolute_time();

let c_start:UInt64 = mach_absolute_time();
quicksort_c(&x_c, CInt(x_c.count))
let c_stop:UInt64 = mach_absolute_time();

Cette fonction convertit l'absolu fois de secondes:

static const uint64_t NANOS_PER_USEC = 1000ULL;
static const uint64_t NANOS_PER_MSEC = 1000ULL * NANOS_PER_USEC;
static const uint64_t NANOS_PER_SEC = 1000ULL * NANOS_PER_MSEC;

mach_timebase_info_data_t timebase_info;

uint64_t abs_to_nanos(uint64_t abs) {
    if ( timebase_info.denom == 0 ) {
        (void)mach_timebase_info(&timebase_info);
    }
    return abs * timebase_info.numer  / timebase_info.denom;
}

double abs_to_seconds(uint64_t abs) {
    return abs_to_nanos(abs) / (double)NANOS_PER_SEC;
}

Voici, en résumé, le compilateur optimazation niveaux:

[-Onone] no optimizations, the default for debug.
[-O]     perform optimizations, the default for release.
[-Ofast] perform optimizations and disable runtime overflow checks and runtime type checks.

Temps en secondes avec [Individualisé] pour n=10_000:

Swift:            0.895296452
C:                0.001223848

Ici est de Swift builtin sort() pour n=10_000:

Swift_builtin:    0.77865783

Ici est [-O] pour n=10_000:

Swift:            0.045478346
C:                0.000784666
Swift_builtin:    0.032513488

Comme vous pouvez le voir, de Swift, de l'amélioration du rendement d'un facteur 20.

Comme par mweathers réponse, réglage [-Ofast] fait la véritable différence, résultant en ces temps de n=10_000:

Swift:            0.000706745
C:                0.000742374
Swift_builtin:    0.000603576

Et pour n=1_000_000:

Swift:            0.107111846
C:                0.114957179
Swift_sort:       0.092688548

À des fins de comparaison, c'est avec [Individualisé] pour n=1_000_000:

Swift:            142.659763258
C:                0.162065333
Swift_sort:       114.095478272

Tellement rapide avec aucun des optimisations était presque 1000x plus lent que C dans ce repère, à ce stade de son développement. D'autre part, avec les deux compilateurs définie sur [-Ofast] Swift effectivement accompli au moins aussi bien, si pas un peu mieux que les C.

Il a été souligné que [-Ofast] la sémantique de la langue, ce qui en fait potentiellement dangereux. C'est ce que Apple états dans Xcode 5.0 notes de version:

Un nouveau niveau d'optimisation -Ofast, disponible dans LLVM, permet des optimisations agressives. -Ofast détend de certains conservateurs, les restrictions, surtout pour les opérations à virgule flottante, qui sont sans danger pour la plupart de code. Il peut apporter d'importants haute performance gagne du compilateur.

Ils ont tous, mais l'avocat il. Si c'est judicieux ou pas, je ne pouvais pas le dire, mais de ce que je peux dire, il semble assez raisonnable d'utiliser [-Ofast] dans un communiqué de presse si vous ne faites pas de haute précision en arithmétique à virgule flottante et que vous en êtes sûr pas de nombre entier ou un tableau des débordements sont possibles dans votre programme. Si vous avez besoin de haute performance et dépassement de contrôles /précis d'arithmétique, puis choisir une autre langue pour le moment.

BETA 3 MISE À JOUR:

n=10_000 avec [-O]:

Swift:            0.019697268
C:                0.000718064
Swift_sort:       0.002094721

Swift en général est un peu plus rapide et il semble que Swift intégré de sorte a bien changé de manière significative.

DERNIÈRE MISE À JOUR:

[Individualisé]:

Swift:   0.678056695
C:       0.000973914

[-O]:

Swift:   0.001158492
C:       0.001192406

[-Ounchecked]:

Swift:   0.000827764
C:       0.001078914

J'ai décidé de prendre un coup d'oeil à cela pour le plaisir, et voici les horaires que je reçois:

Swift 4.0.2           :   0.83s (0.74s with `-Ounchecked`)
C++ (Apple LLVM 8.0.0):   0.74s

Swift

//Swift 4.0 code
import Foundation

func doTest() -> Void {
    let arraySize = 10000000
    var randomNumbers = [UInt32]()

    for _ in 0..<arraySize {
        randomNumbers.append(arc4random_uniform(UInt32(arraySize)))
    }

    let start = Date()
    randomNumbers.sort()
    let end = Date()

    print(randomNumbers[0])
    print("Elapsed time: \(end.timeIntervalSince(start))")
}

doTest()

Résultats:

Swift 1.1

xcrun swiftc --version
Swift version 1.1 (swift-600.0.54.20)
Target: x86_64-apple-darwin14.0.0

xcrun swiftc -O SwiftSort.swift
./SwiftSort     
Elapsed time: 1.02204304933548

Swift 1.2

xcrun swiftc --version
Apple Swift version 1.2 (swiftlang-602.0.49.6 clang-602.0.49)
Target: x86_64-apple-darwin14.3.0

xcrun -sdk macosx swiftc -O SwiftSort.swift
./SwiftSort     
Elapsed time: 0.738763988018036

Swift 2.0

xcrun swiftc --version
Apple Swift version 2.0 (swiftlang-700.0.59 clang-700.0.72)
Target: x86_64-apple-darwin15.0.0

xcrun -sdk macosx swiftc -O SwiftSort.swift
./SwiftSort     
Elapsed time: 0.767306983470917

Il semble être le même rendement que si je compile avec -Ounchecked.

Swift 3.0

xcrun swiftc --version
Apple Swift version 3.0 (swiftlang-800.0.46.2 clang-800.0.38)
Target: x86_64-apple-macosx10.9

xcrun -sdk macosx swiftc -O SwiftSort.swift
./SwiftSort     
Elapsed time: 0.939633965492249

xcrun -sdk macosx swiftc -Ounchecked SwiftSort.swift
./SwiftSort     
Elapsed time: 0.866258025169373

Il semble y avoir eu une régression de la performance de Swift 2.0 Swift 3.0, et je vois aussi une différence entre -O et -Ounchecked pour la première fois.

Swift 4.0

xcrun swiftc --version
Apple Swift version 4.0.2 (swiftlang-900.0.69.2 clang-900.0.38)
Target: x86_64-apple-macosx10.9

xcrun -sdk macosx swiftc -O SwiftSort.swift
./SwiftSort     
Elapsed time: 0.834299981594086

xcrun -sdk macosx swiftc -Ounchecked SwiftSort.swift
./SwiftSort     
Elapsed time: 0.742045998573303

Swift 4 améliore la performance de nouveau, tout en conservant un écart entre -O et -Ounchecked. -O -whole-module-optimization ne semble pas faire une différence.

C++

#include <chrono>
#include <iostream>
#include <vector>
#include <cstdint>
#include <stdlib.h>

using namespace std;
using namespace std::chrono;

int main(int argc, const char * argv[]) {
    const auto arraySize = 10000000;
    vector<uint32_t> randomNumbers;

    for (int i = 0; i < arraySize; ++i) {
        randomNumbers.emplace_back(arc4random_uniform(arraySize));
    }

    const auto start = high_resolution_clock::now();
    sort(begin(randomNumbers), end(randomNumbers));
    const auto end = high_resolution_clock::now();

    cout << randomNumbers[0] << "\n";
    cout << "Elapsed time: " << duration_cast<duration<double>>(end - start).count() << "\n";

    return 0;
}

Résultats:

Apple Clang 6.0

clang++ --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

clang++ -O3 -std=c++11 CppSort.cpp -o CppSort
./CppSort     
Elapsed time: 0.688969

Apple Clang 6.1.0

clang++ --version
Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix

clang++ -O3 -std=c++11 CppSort.cpp -o CppSort
./CppSort     
Elapsed time: 0.670652

Apple Clang 7.0.0

clang++ --version
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

clang++ -O3 -std=c++11 CppSort.cpp -o CppSort
./CppSort     
Elapsed time: 0.690152

Apple Clang 8.0.0

clang++ --version
Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin15.6.0
Thread model: posix

clang++ -O3 -std=c++11 CppSort.cpp -o CppSort
./CppSort     
Elapsed time: 0.68253

Apple Clang 9.0.0

clang++ --version
Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin16.7.0
Thread model: posix

clang++ -O3 -std=c++11 CppSort.cpp -o CppSort
./CppSort     
Elapsed time: 0.736784

Verdict

Que de la rédaction de ce document, Swift est un peu rapide, mais pas encore aussi rapide que du C++de tri lors de la compilation avec -O, avec les compilateurs & les bibliothèques. Avec -Ounchecked, il semble être aussi rapide que du C++ dans Swift 4.0.2 et Apple LLVM 9.0.0.

De Xcode 7, vous pouvez activer Fast, Whole Module Optimization. Cela devrait accroître vos performances immédiatement.

La question principale qui est mentionné par d'autres, mais ne l'appelle pas assez, c'est que -O3 ne fait rien du tout dans Swift (et n'a jamais) donc lorsqu'il est compilé avec qui il est effectivement non-optimisés (-Onone).

Option noms ont changé au fil du temps de sorte que certains autres réponses ont obsolètes drapeaux pour les options de compilation. Corriger les options actuelles (Swift 2.2) sont:

-Onone //Debug - slow
-O     //Optimised
-O -whole-module-optimization //Optimised across files

Ensemble de module d'optimisation a un ralentissement de la compilation, mais la possibilité d'en optimiser tous les fichiers dans le module, c'est à dire à l'intérieur de chaque cadre et dans le code de l'application, mais pas entre eux. Vous devriez l'utiliser pour quoi que ce soit critique pour les performances)

Vous pouvez également désactiver les contrôles de sécurité pour encore plus de vitesse, mais avec toutes les affirmations et les conditions préalables et pas seulement les personnes à mobilité réduite optimisée sur la base qu'ils sont corrects. Si vous avez jamais touché à une assertion cela signifie que vous êtes dans un comportement indéterminé. Utiliser avec une extrême prudence et seulement si vous déterminez que le gain de vitesse est intéressant pour vous (par des tests). Si vous trouvez qu'il est précieux pour le code, je vous recommandons de séparer ce code dans un cadre distinct et seulement désactiver les contrôles de sécurité pour ce module.

Swift 4.1 introduit de nouvelles -Osize optimisation de la mode.

Dans Swift 4.1 le compilateur prend en charge un nouveau mode optimisation
permet de dédié des optimisations pour réduire la taille du code.

La Swift compilateur est livré avec un puissant optimisations. Lors de la compilation
avec -O, le compilateur essaie de transformer le code de sorte qu'il s'exécute
avec des performances maximales. Cependant, cette amélioration dans l'exécution
les performances peuvent parfois venir avec un compromis de l'augmentation de la taille du code.
Avec le nouveau -Osize optimisation de la mode, l'utilisateur a le choix de
compiler pour un minimum de taille de code, plutôt que pour une vitesse maximale.

Pour permettre l'optimisation de la taille du mode sur la ligne de commande, utilisez -Osize
au lieu de O.

Pour en savoir plus : https://swift.org/blog/osize/