Permalänk

Snabbast på sortering?

Man hittar ibland uppgiften på nätet att mergesort och radixsort skulle vara snabbare än quicksort.
Men jag har alltid mätt att quicksort är snabbast. Någon som har sett något annat?

Permalänk
Medlem

Det underlättar om du nämner vilket språk det gäller.

Visa signatur

www.fckdrm.com - DRM år 2025? Ha pyttsan.

Permalänk
Medlem

Frågar du rent allmänt - snabbast sökning? Finns inget svar. Quick sort är generellt bra, men finns bättre sökalgoritmer under specifika förhållanden.

Permalänk
Medlem

Quicksort är snabb, ja. Men i värsta fall, otur eller riggat, så kan den bli O(n^2).

Mergesort är alltid O(n*Log(n)).

Mergesort brukar dock mer minne då den skriver till nya arrayer medan quicksort kan göras på befintlig samling.

Visa signatur

i5-7600k . GTX 1080 . 16 GB

Permalänk
Medlem
Skrivet av Greyguy1948:

Man hittar ibland uppgiften på nätet att mergesort och radixsort skulle vara snabbare än quicksort.
Men jag har alltid mätt att quicksort är snabbast. Någon som har sett något annat?

Vilken som är snabbast för ett specifikt fall beror ju väldigt mycket på exakt hur respektive algortim är implementerad, och för många sorteringsalgoritmer så beror körtiden även på hur indata ser ut.
Vad som är snabbast för att sortera en liten lista på bara ett par hundra tal behöver inte vara snabbast för att sortera en array av ett par hundra miljarder tal. Och vice versa.

Quicksort är t.ex. i genomsnitt en ganska effektiv sorteringsalgoritm, men för vissa indata så kan den degenerera till att behöva O(n^2) jämförelser istället för det genomsnittliga O(n*log n), och då är den inte alls snabb.

Mergesort har många trevliga egenskaper, men kräver temporärt minne som buffert, och finns det inte tillräckligt med RAM så att datorn behöver swappa ´till disk, så blir det plötsligt en väldigt långsam sortering.

Det finns ingen sorteringsalgoritm som alltid är snabbast, utan de bra sorteringsalgoritmerna har alla olika egenskaper och fungerar olika bra i olika situationer.

Permalänk
Medlem

Den här sidan är rätt bra med förklaringar och animationer hur de flesta vanliga algoritmerna fungerar och deras för och nackdelar: https://www.toptal.com/developers/sorting-algorithms

Visa signatur

Data: Corsair 5000D Airflow + B650 Aorus Elite AX + AMD 7800X3D + Gigabyte 4080 Super + 64GB Kingston + 2TB Crucial T700 + 850W Seasonic Focus GX
Ljud: Cambridge Audio DacMagic + SPL Phonitor 2 + AKG K812
Bild: MSI MAG 274UPF (27" 4K)

Permalänk
Medlem
Permalänk

Bristen på RAM är nog inget stort problem idag men bristen på cache. Raspberry Pi 4 där jag har det mesta av mina data har L2=1MB. Detta drabbar nog mergesort hårdare än de andra. AMD med 32 MB L3 borde gynna mergesort. Radixsort har en annan egenskap som är unik. Sortering av 1 mega 16bitarstal borde gå dubbelt så snabbt som 1 mega 32bitarstal.

Permalänk
Medlem

Som många säger, så beror det ju på lite.

Finns ett cheat sheet som man kan referera till och matcha mot sina parametrar.

https://www.bigocheatsheet.com/

Permalänk

För den som använder Go eller Golang:
http://rosettacode.org/wiki/Sorting_algorithms/Cocktail_sort_...
Här jämför man två algoritmer.

Förutom Go använder jag C, C++, Fortran och Pascal
Om man inte använder egen timer kan man köra time i unix/linux
Då får man hela tiden men att skapa en array och fylla den med slumptal bär ju vara lika för alla algoritmer.

Permalänk
Medlem

Det beror som sagt på vad man vill sortera. Men vad många standardbibliotek använder är introsort, som kombinerar quicksort, heapsort och insertion sort.

Permalänk

Dramatisk försämring av quicksort:
a[i] = 100000 +rand()%20 i stället för a[i] = rand()%200000
Från 49 ms till 2770 ms på 200 000 tal
Mergesort från 133 ms till 119 ms dvs en liten förbättring!

Permalänk
Medlem
Skrivet av Greyguy1948:

Dramatisk försämring av quicksort:
a[i] = 100000 +rand()%20 i stället för a[i] = rand()%200000
Från 49 ms till 2770 ms på 200 000 tal
Mergesort från 133 ms till 119 ms dvs en liten förbättring!

Count sort (som vet att minsta talet är 0 och största är M-1), stabilt men ej in-place:
N=200000 M=20 t=1 ms
N=200000 M=200000 t=1 ms

N=2000000 M=20 t=6 ms
N=20000000 M=20 t=65 ms
N=200000000 M=20 t=851 ms

N=2000000 M=200000 t=10 ms
N=20000000 M=200000 t=180 ms
N=200000000 M=200000 t=2332 ms

Permalänk

Som @perost nämner så är de oftast någon typ av hybrid som används. Har du specifika dataset du har kontroll på men karaktäristiska egenskaper kan de gå att optimera just för dessa. Här är några exempel på hybrida algoritmer. Dock helt klart överkurs om du bara ska sortera något och vill testa skriva en egen algoritm, då kan du hålla dig till de klassiska som nämnts ovan.

Visa signatur

=)

Permalänk
Medlem

Semi-OT, men det första jag kom att tänka på är den här godingen:

Visa signatur

9950X3D | 5080

Permalänk
Medlem

Varje gång jag skall sortera något tittar jag igenom denna. De har ett gäng för olika metoder

Permalänk
Medlem

@Xerbee: Hahaha, klockren!

Visa signatur

9950X3D | 5080

Permalänk
Medlem
Skrivet av backfeed:

Semi-OT, men det första jag kom att tänka på är den här godingen:

https://www.youtube.com/watch?v=8MsTNqK3o_w

Herrejösses, jag spolade igenom och tittade på den i minst 40 minuter

Visa signatur

ASRock X870E Nova WIFI / Ryzen 9800X3D (CO: -45 AC) / Corsair Vengance 64GB DDR5 6000MHz CL30 / Crucial T705 1TB Gen5 + 5.5TB sekundära / ASUS TUF 4080 Gaming OC / Seasonic Focus GX 850W ATX 3.1 / Acer Predator XB273UGX 1440p 270 Hz G-Sync / FD Torrent Compact / Phantom Spirit 120 SE / Evo 4 / Sennheiser IE 300 / Rode NT1-A
Synology 1621+ 6*16 / 1513+ 5*8 / LG CX 65" / XBox Series X / Switch 2 / Steamdeck OLED