Greitas beta: rūšiavimo masyvai

Aš įgyvendinau algoritmą „Swift“ beta versijoje ir pastebėjau, kad spektaklis buvo labai blogas. Žvelgiant giliau, supratau, kad viena iš kliūčių yra kažkas taip paprasta, kaip rūšiavimo masyvai. Atitinkama dalis yra čia:

 let n = 1000000 var x = [Int](repeating: 0, count: n) for i in 0..<n { x[i] = random() } // start clock here let y = sort(x) // stop clock here 

C ++ sistemoje panaši operacija mano kompiuteryje trunka 0,06 sekundes .

Pythone trunka 0,6 s (be triukų, tik y = surūšiuoti (x) sveikųjų skaičių sąrašui).

„Swift“ trunka 6 sekundes, jei ją sukompiliuoju su tokia komanda:

 xcrun swift -O3 -sdk 'xcrun --show-sdk-path --sdk macosx' 

Ir jei reikės surinkti šią komandą, užtruks net 88 sekundes.

 xcrun swift -O0 -sdk 'xcrun --show-sdk-path --sdk macosx' 

Sinchronizavimas Xcode su „Release“ ir „Debug“ statiniais yra panašus.

Kas čia negerai? Aš galėjau suprasti kai kuriuos našumo nuostolius, palyginti su C + +, bet ne 10 kartų sulėtėjusį, palyginti su grynuoju Python.


„Edit“: „ mweathers“ pastebėjo, kad -O3 keitimas į „ -Ofast “ šį kodą veikia beveik taip pat greitai, kaip C ++ versija! Tačiau, -Ofast keičia kalbos kalbos semantiką - mano bandyme buvo išjungta sveikojo skaičiaus perpildymo ir perpildymo indeksavimo kontrolė . Pavyzdžiui, su „ -Ofast šis „Swift“ kodas veikia be -Ofast (ir spausdina šiukšles):

 let n = 10000000 print(n*n*n*n*n) let x = [Int](repeating: 10, count: n) print(x[n]) 

Taigi, „ -Ofast , ko norime; „Swift“ esmė yra tai, kad turime apsauginius tinklus. Žinoma, saugumo sistemos daro tam tikrą poveikį veiklai, tačiau jos neturėtų padaryti programų 100 kartų lėčiau. Atminkite, kad „Java“ jau patikrina masyvų ribas, o tipiškais atvejais sulėtėjimas yra -ftrapv mažesnis. Ir -ftrapv ir GCC, mes gavome -ftrapv kad patikrintume (sveikasis skaičius) sveikasis skaičius, o ne taip lėtas, arba.

Todėl kyla klausimas: kaip galime Swift efektyviai veikti, neprarandant saugos tinklų?


Redaguoti 2: atlikiau keletą papildomų testų su labai paprastais linijų ciklais

 for i in 0..<n { x[i] = x[i] ^ 12345678 } 

(Čia xor operacija paprasčiausiai palengvina susirinkimo kodo atitinkamos kilpos suradimą. Bandžiau pasirinkti operaciją, kurią lengva aptikti, bet „nekenksmingą“ ta prasme, kad nereikėtų atlikti jokių susijusių patikrinimų su sveikojo skaičiaus perpildymais.)

Vėlgi buvo didelis skirtumas tarp -O3 ir -Ofast . Taigi, aš pažvelgiau į kūrimo kodą:

  • Su -Ofast gaunu beveik tai, ko tikėjausi. Atitinkama dalis yra ciklas su 5 mašinų kalbos instrukcijomis.

  • Su -O3 aš gaunu tai, kas buvo daugiau nei mano baisiausia vaizduotė. Vidinė kilpa užima 88 eilutes surinkimo kodo. Aš ne bandžiau suprasti visa tai, bet labiausiai įtartinos dalys yra 13 skambučių „callq _swift_retain“ ir 13 dar vadinasi „callq _swift_release“. Tai reiškia, kad vidinėje kilpoje skambina 26 paprogramės !


Redaguoti 3: komentaruose „Ferruccio“ paprašė kriterijų, kurie yra teisingi ta prasme, kad jie nesiremia integruotomis funkcijomis (pvz., Rūšiavimu). Manau, kad ši programa yra gana geras pavyzdys:

 let n = 10000 var x = [Int](repeating: 1, count: n) for i in 0..<n { for j in 0..<n { x[i] = x[j] } } 

Čia nėra aritmetikos, todėl nereikia nerimauti dėl sveikų skaičių perpildymo. Vienintelis dalykas, kurį mes darome, yra tik daug nuorodų į masyvus. Rezultatai čia - „Swift -O3“ praranda beveik 500 kartų, palyginti su „Ofast“:

  • C ++ -O3: 0,05 s
  • C ++ -00: 0,4 s
  • Java: 0,2 s
  • Python su PyPy: 0,5 s
  • Python: 12 s
  • Swift -Ofast: 0,05 s
  • Swift -O3 23 s
  • Swift -00: 443 s

(Jei esate susirūpinęs, kad kompiliatorius gali visiškai optimizuoti nereikalingas kilpas, galite ją pakeisti, pvz., Į x[i] ^= x[j] , ir pridėti spausdinimo pareiškimą, kuris išvesties x[0] . datos bus labai panašios.)

Taip, čia „Python“ įgyvendinimas buvo kvailas, švarus „Python“ įgyvendinimas su sveikųjų skaičių ir įdėtinių kilpų sąrašu. Tai turėtų būti daug lėtesnė nei neoptimali „Swift“. Atrodo, kad kažkas rimtai sulaužyta su Swift ir indeksavimo matricomis.


Redaguoti 4: Atrodo, kad šios problemos (taip pat kai kurios kitos našumo problemos) yra nustatytos Xcode 6 beta 5 versijoje.

Jei norite rūšiuoti, dabar turiu šiuos laikus:

  • c>
  • swiftc -Ofast: 0,1 s
  • swiftc -O: 0,1 s
  • swiftc: 4 s

Įdėtoms kilpoms:

  • c>
  • swiftc -Ofast: 0,3 s
  • swiftc -O: 0,4 s
  • swiftc: 540s

Atrodo, kad nebėra jokios priežasties naudoti nesaugų „ -Ofast (dar žinomas kaip „ -Ounchecked ); -O gamina vienodai gerą kodą.

870
08 июня '14 в 2:53 2014-06-08 02:53 Jukka Suomela yra nustatyta birželio 8 d. 14 val. 2:53 2014-06-08 02:53
@ 9 atsakymai

Šiuo testu Dr Swift 1.0 dabar veikia taip greitai, kaip C, naudojant numatytąjį išleidimo optimizavimo lygį [-O].


Čia yra greitas „Swift“ beta versijos:

 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( start, r + 1) quicksort_swift( r + 1, end) } 

Ir tas pats 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); } 

Abu darbai:

 var a_swift:CInt[] = [0,5,2,8,1234,-1,2] var a_c:CInt[] = [0,5,2,8,1234,-1,2] quicksort_swift( 0, a_swift.count) quicksort_c( CInt(a_c.count)) // [-1, 0, 2, 2, 5, 8, 1234] // [-1, 0, 2, 2, 5, 8, 1234] 

Abi yra vadinamos toje pačioje programoje, kaip ir parašyta.

 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( 0, x_swift.count) let swift_stop:UInt64 = mach_absolute_time(); let c_start:UInt64 = mach_absolute_time(); quicksort_c( CInt(x_c.count)) let c_stop:UInt64 = mach_absolute_time(); 

Tai konvertuoja absoliutų laiką į sekundes:

 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( } return abs * timebase_info.numer / timebase_info.denom; } double abs_to_seconds(uint64_t abs) { return abs_to_nanos(abs) / (double)NANOS_PER_SEC; } 

Čia pateikiama kompiliatoriaus optimizavimo lygių santrauka:

 [-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. 

Laikas sekundėmis nuo [-O no], kai n = 10_000 :

 Swift: 0.895296452 C: 0.001223848 

Čia yra integruotas „Swift“ () rūšiuoti n = 10_000 :

 Swift_builtin: 0.77865783 

Čia yra [-O] n = 10_000 :

 Swift: 0.045478346 C: 0.000784666 Swift_builtin: 0.032513488 

Kaip matote, „Swift“ našumas pagerėjo 20 kartų.

Pagal Mweather atsakymą , [-O greitas] nustatymas daro tikrą skirtumą, dėl kurio šiais laikais n = 10_000 :

 Swift: 0.000706745 C: 0.000742374 Swift_builtin: 0.000603576 

Ir n = 1_000_000 :

 Swift: 0.107111846 C: 0.114957179 Swift_sort: 0.092688548 

Palyginimui, tai yra su [-O none], kai n = 1_000_000 :

 Swift: 142.659763258 C: 0.162065333 Swift_sort: 114.095478272 

Taigi, šiame vystymosi etape „Swift“ be optimizavimo buvo beveik 1000 kartų lėčiau negu C. Kita vertus, kai abu kompiliatoriai nustatė [-O greitai], „Swift“ dirbo bent jau taip pat, jei ne šiek tiek geriau nei C.

Pastebėta, kad [-O greitai] keičia kalbos semantiką, todėl ji gali būti nesaugi. „Apple“ sako „Xcode 5.0“ leidinio pastabose:

Naujasis optimizavimo lygis -O greitai, prieinamas LLVM, užtikrina agresyvų optimizavimą. -O greitai atlaisvina kai kuriuos konservatyvius suvaržymus, daugiausia plaukiojančio taško operacijoms, kurios daugeliui kodų yra saugios. Tai gali sukelti didelius našumo kompiliatorius.

Jie ją beveik apsaugo. Nesvarbu, ar tai išmintinga, ar ne, aš negaliu pasakyti, bet iš to, ką galiu pasakyti, atrodo pakankamai pagrįsta naudoti [-O greitai] spaudoje, jei nevykdote didelio tikslumo slankiojo kablelio aritmetikos ir esate tikri, kad jūsų programa nėra sveikasis skaičius arba masyvo perpildymas Jei jums reikia aukšto našumo ir perpildymo patikrinimų / tikslaus aritmetikos, pasirinkite kitą kalbą.

BETA 3 UPDATE:

n = 10_000 s [-O] :

 Swift: 0.019697268 C: 0.000718064 Swift_sort: 0.002094721 

„Swift“ paprastai veikia šiek tiek greičiau, ir atrodo, kad „Swift“ įmontuotas rūšiavimas labai pasikeitė.

GALUTINIS ATNAUJINIMAS:

[-O ne] :

 Swift: 0.678056695 C: 0.000973914 

[-O] :

 Swift: 0.001158492 C: 0.001192406 

[-O nepatvirtinta] :

 Swift: 0.000827764 C: 0.001078914 
428
08 июня '14 в 4:36 2014-06-08 04:36 Juozapo Marko atsakymas birželio 8 d. 14 d. 4:36 2014-06-08 04:36

Tl; DR : Taip, vienintelis „Swift“ įgyvendinimas vyksta lėtai, dabar. Jei jums reikia greito, skaitmeninio (ir kito tipo kodų, galbūt) kodo, tiesiog eikite į kitą. Ateityje turėtumėte pervertinti savo pasirinkimą. Tai gali būti pakankamai gera daugumai aukštesnio lygio programų.

Iš to, ką matau SIL ir LLVM IR, atrodo, kad jiems reikia daug optimizacijų, skirtų ištrinti įrašus ir leidimus, kuriuos galima įgyvendinti „ C> („Objective-C“), tačiau jie jų dar neperkėlė. Tai teorija, su kuria aš einu (šiuo metu ... vis dar turiu patvirtinti, kad C>

Kaip jau minėjo daugelis kitų, - „ -Ofast visiškai nesaugi ir keičia kalbos semantiką. Man tai yra „Jei ketinate jį naudoti, tiesiog naudokite kitą kalbą“. Jei tai pasikeis, aš vėliau įvertinsiu šį pasirinkimą.

-O3 suteikia mums daug swift_retain ir swift_release , kurie atvirai neatrodo taip, lyg jie turėtų būti šiame pavyzdyje. Optimizatorius turėjo pašalinti (dauguma jų) AFAICT, nes jis žino daugumą informacijos apie masyvą ir žino, kad jis turi (bent jau) tvirtą ryšį su juo.

Ji neturėtų skirti daugiau, jei netgi neskambina funkcijų, galinčių paleisti objektus. Nemanau, kad masyvo konstruktorius gali grąžinti masyvą, kuris yra mažesnis už prašomą, o tai reiškia, kad daugelis pasirinktų patikrinimų yra nenaudingi. Jis taip pat žino, kad sveikasis skaičius niekada nebus didesnis nei 10k, todėl gali būti optimizuoti perpildymo patikrinimai (ne dėl „ -Ofast , o dėl kalbos semantikos (nieko kito nepakeičia ir negali prieiti prie jo, bet ne Int .

border=0

Kompiliatorius gali nepajėgti išpakuoti masyvo ar masyvo elementų, nes jie perduodami sort() , kuri yra išorinė funkcija ir turėtų gauti tikėtinus argumentus. Tai verčia mus netiesiogiai naudoti „ Int vertes, kurios sukeltų šiek tiek lėčiau. Tai gali keistis, jei kompiliatoriui buvo įdiegta ir buvo įdiegta bendro pobūdžio (ne kelių metodų) funkcija.

Tai yra labai nauja (atviro kodo) kalba, ir ji peržengia tai, ką manau, yra daug pakeitimų, nes yra žmonių (stipriai), susijusių su „Swift“ kalba, reikalaujanti atsiliepimų, ir visi sako, kad kalba nėra baigta ir bus pasikeitė

Naudojamas kodas:

 import Cocoa let swift_start = NSDate.timeIntervalSinceReferenceDate(); let n: Int = 10000 let x = Int[](count: n, repeatedValue: 1) for i in 0..n { for j in 0..n { let tmp: Int = x[j] x[i] = tmp } } let y: Int[] = sort(x) let swift_stop = NSDate.timeIntervalSinceReferenceDate(); println("\(swift_stop - swift_start)s") 

PS: Aš nesu „Objective-C“ ekspertas, o ne visi įrankiai iš „ Coao“ , „Objective-C“ ar „Swift“ vykdymo. Aš taip pat galėčiau pasiūlyti keletą dalykų, kurių aš ne parašiau.

101
09 июня '14 в 9:30 2014-06-09 09:30 filcab atsakymas birželio 9 d. 14 d. 9:30 2014-06-09 09:30

Nusprendžiau pažvelgti į jį įdomiai, ir čia yra laikas, kai gausiu:

 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() 

Rezultatai:

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 (swift> 

„Swift 2.0“

 xcrun swiftc --version Apple Swift version 2.0 (swift> 

Atrodo, kad tą patį spektaklį, jei aš -Ounchecked su -Ounchecked .

„Swift 3.0“

 xcrun swiftc --version Apple Swift version 3.0 (swift> 

Atrodo, kad nuo „Swift 2.0“ iki „Swift 3.0“ įvyko veiklos regresija, ir aš pirmą kartą matau skirtumą tarp -O ir -Ounchecked .

„Swift 4.0“

 xcrun swiftc --version Apple Swift version 4.0.2 (swift> 

„Swift 4“ dar kartą pagerina našumą išlaikydama tarpą tarp -O ir -Ounchecked . -O -whole-module-optimization neatrodo -O -whole-module-optimization .

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; } 

Rezultatai:

„Apple C>

 c> 

„Apple C>

 c> 

„Apple C>

 c> 

„Apple C>

 c> 

„Apple C>

 c> 

Sprendimas

Šio rašymo metu „Swift“ rūšiavimas yra greitas, bet ne toks greitas, kaip ir C ++ - rūšiuojant su -O , su pirmiau pateiktais kompiliatoriais ir bibliotekomis. Su „ -Ounchecked jis atrodo taip greitai, kaip „C ++“ „Swift 4.0.2“ ir „Apple LLVM 9.0.0“.

45
27 окт. atsakymas pateikiamas Sužinokite OpenGL ES 27 okt. 2014-10-27 00:47 '14 ne 0:47 2014-10-27 00:47

The Swift Programming > :

Standartinė biblioteka „Sort Function Swifts“ suteikia funkciją, vadinamą rūšiuoti, kuri rūšiuoja žinomų tipų reikšmių masyvą, pagrįstą uždaromos rūšies išvestimi, kurią pateikiate. Po to, kai rūšiavimas yra baigtas, rūšiavimo funkcija grąžina naują tos pačios rūšies ir dydžio masyvą, kaip ir senasis, su jo elementais teisinga tvarka.

sort funkcija turi dvi deklaracijas.

Numatytasis skelbimas, leidžiantis nurodyti palyginimo pabaigą:

 func sort<T>(array: T[], pred: (T, T) -> Bool) -> T[] 

Ir antroji deklaracija, kuri užima tik vieną parametrą (masyvą) ir yra „sunkiai užkoduota naudoti mažiau nei lyginamoji priemonė“.

 func sort<T : Comparable>(array: T[]) -> T[] Example: sort( _arrayToSort_ ) { $0 > $1 } 

Bandau modifikuotą jūsų kodo versiją žaidimo aikštelėje su papildomu uždarymu, kad galėčiau atidžiau stebėti šią funkciją, ir sužinojau, kad n nustačius 1000, uždarymas buvo vadinamas maždaug 11 000 kartų.

 let n = 1000 let x = Int[](count: n, repeatedValue: 0) for i in 0..n { x[i] = random() } let y = sort(x) { $0 > $1 } 

Tai nėra veiksminga funkcija, rekomenduoju naudoti geriausią rūšiavimo funkcijos įgyvendinimą.

EDIT:

Aš peržiūrėjau „Quicksort“ wikipedijos puslapį ir parašiau „Swift“ įgyvendinimą. Čia yra visa programa, kurią naudoju (žaidimų aikštelėje)

 import Foundation func quickSort(inout array: Int[], begin: Int, end: Int) { if (begin < end) { let p = partition( begin, end) quickSort( begin, p - 1) quickSort( p + 1, end) } } func partition(inout array: Int[], left: Int, right: Int) -> Int { let numElements = right - left + 1 let pivotIndex = left + numElements / 2 let pivotValue = array[pivotIndex] swap(  var storeIndex = left for i in left..right { let a = 1 // <- Used to see how many comparisons are made if array[i] <= pivotValue { swap(  storeIndex++ } } swap(  // Move pivot to its final place return storeIndex } let n = 1000 var x = Int[](count: n, repeatedValue: 0) for i in 0..n { x[i] = Int(arc4random()) } quickSort( 0, x.count - 1) // <- Does the sorting for i in 0..n { x[i] // <- Used by the playground to display the results } 

Naudodamiesi šia reikšme n = 1000, aš tai nustatiau

  • quickSort () buvo vadinama apie 650 kartų
  • buvo atlikta apie 6000 apsikeitimo sandorių,
  • ir yra apie 10 000 palyginimų

Atrodo, kad įmontuotas rūšiavimo metodas (ar artimas) greitai surūšiuotas ir labai lėtas ...

29
08 июня '14 в 3:29 2014-06-08 03:29 atsakymą davė David Skrundz, birželio 8 d. 14 d., 03:29 2014-06-08 03:29

Su „Xcode 7“ galite įgalinti Fast, Whole Module Optimization . Tai turėtų nedelsiant padidinti našumą.

2019

16
11 июня '15 в 19:56 2015-06-11 19:56 atsakymą Antoine pateikė birželio 15 d. 15 val. 19.56 2015-06-11 19:56

Numatomas „Swift Array“ našumas:

Aš parašiau savo testą, lyginantį „Swift“ su C / Objective-C. Mano bandyme skaičiuojami primes. Jis naudoja daugybę ankstesnių pradžių, kad surastų paprastus veiksnius kiekviename naujame kandidate, todėl jis yra gana greitas. Tačiau tonai skaito masyvą ir mažiau rašo masyvams.

Aš iš pradžių bandė prieš Swift 1.2. Nusprendžiau atnaujinti projektą ir paleisti jį prieš „Swift 2.0“.

Projektas leidžia jums pasirinkti tarp paprastų greitųjų matricų ir „Swift“ nesaugių atminties buferių naudojimą pagal masyvo semantiką.

C / Objective-C galite pasirinkti naudoti NSArrays arba C malloced masyvus.

Bandymo rezultatai atrodo labai panašūs į sparčiausią, minimalų kodo optimizavimą ([-0s]) arba sparčiausiai, agresyviai ([-0f]]) optimizavimą.

„Swift 2.0“ našumas vis dar yra baisus, kai kodų optimizavimas yra išjungtas, o C / Objective-C našumas yra vidutiniškai lėčiau.

Esmė yra ta, kad skaičiavimai, pagrįsti „Malloc'd“ C masyvu, yra greičiausiai, kukliu lygiu

Naudojant greitesnį ir mažiausią kodo optimizavimą, „Swift“ su nesaugiais buferiais ilgiau nei 1,19X - 1,20X ilgiau nei C malloc'd masyvai. Skirtumas, atrodo, šiek tiek mažesnis greitai ir agresyviai optimizuojant (Swift atrodo labiau kaip 1,18x, 1,16x daugiau nei C.)

Jei naudojate įprastas „Swift“ matricas, skirtumas su C yra šiek tiek didesnis. („Swift“ trunka ~ 1.22–1.23.)

„Swift DRAMATICALLY greitesnės nei „Swift 1.2“ / „Xcode 6“. Jų našumas yra toks arti „Swift“ nesaugių buferinių matricų, kad naudojant nesaugius atminties buferius, jų nebėra.

„BTW“, „C-C“ tikslumas „NSArray“ nyksta. Jei ketinate naudoti savo konteinerių objektus abiem kalbomis, „Swift“ yra greičiau DRAMATICALLY .

Galite patikrinti savo projektą „github“ sistemoje „ SwiftPerformanceBenchmark“

Ji turi paprastą vartotojo sąsają, kuri supaprastina statistikos rinkimą.

Įdomu tai, kad „Swift“ rūšiavimas yra šiek tiek greitesnis nei „C“, tačiau „Swift“ šis algoritmas yra dar greitesnis.

9
26 февр. Atsakymas duotas Duncan C 26 Feb. 2016-02-26 04:31 '16 at 4:31 am 2016-02-26 04:31

Pagrindinė problema, kurią paminėjo kiti, bet nepakankamai sukelta, yra tai, kad -O3 nieko neveikia „Swift“ (ir niekada), taigi, rengiant jį nėra efektyviai optimizuotas ( -Onone ).

Funkcijų pavadinimai laikui bėgant pasikeitė, todėl kai kuriems kitiems atsakymams yra pasenusios vėliavėlės. Teisingi dabartiniai nustatymai (Swift 2.2):

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

Viso modulio optimizavimas vyksta lėčiau, tačiau gali optimizuoti modulio failus, tai yra, kiekvienos struktūros viduje ir pagal faktinį programos kodą, bet ne tarp jų. Turite tai naudoti bet kokiam kritiniam našumui)